www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2009/07/22/11:53:05

X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Wed, 22 Jul 2009 17:52:41 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Yesterday's CVS ci solved VBoxSharedFolderFS issues
Message-ID: <20090722155241.GM27613@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4A6732E1 DOT 8000103 AT shaddybaddah DOT name>
MIME-Version: 1.0
In-Reply-To: <4A6732E1.8000103@shaddybaddah.name>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Jul 23 01:40, Shaddy Baddah wrote:
> Hi,
>
> I've been trying to work through a problem with running cygwin from a
> VBoxSharedFolderFS (VirtualBox) folder mounted on my guest host. I've
> tried to work through the problem on my own, as I would imagine that
> VBoxSharedFolderFS support in cygwin is of almost zero importance.
>
> However I thought it at least interesting to note that yesterday's CVS
> checkins (just as a coincidence, I've been working through the problem
> over the last couple of days) seem to have made this work a lot
> better. Before these checkins, I could not start bash. It would take
> up full utilisation of the CPU, and could only be killed through the
> task manager. ash was working in its place, but behaviour of almost
> all the tools was inconsistent.
>
> The only thing obviously broken now are symlinks. I've done some
> debugging and tracked it down to the fact that any call like this:
>
> path.c:2254:      if (NT_SUCCESS (status)
> path.c:2255:      && NT_SUCCESS (status
> path.c:2256:             = NtQueryInformationFile (h, &io, &fbi, sizeof fbi,
> path.c:2257:                           FileBasicInformation)))
>
> will return STATUS_NOT_SUPPORTED. I will need to do some further
> learning to understand if this is a show stopper for symlinks,
> although any wisdom dispensed would be greatly appreciated.

Is ity possible that the status code is not the one from
the NtQueryInformationFile call but rather from the
NtCreateFile call before?  In that case the first NT_SUCCESS (status)
is what fails.

A couple of lines above, line 2211ff, there's this:

      /* No right to access EAs or EAs not supported? */
      if (status == STATUS_ACCESS_DENIED || status == STATUS_EAS_NOT_SUPPORTED
          /* Or a bug in Samba 3.2.x (x <= 7) when accessing a share's root dir
             which has EAs enabled? */
          || status == STATUS_INVALID_PARAMETER)
        {
          no_ea = true;
          /* If EAs are not supported, there's no sense to check them again
             whith suffixes attached.  So we set eabuf/easize to 0 here once. */
          if (status == STATUS_EAS_NOT_SUPPORTED)

There are two places which check for STATUS_EAS_NOT_SUPPORTED.
If you check additionally for STATUS_NOT_SUPPORTED in both places,
does it work now?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019