X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 21 Oct 2011 11:10:56 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: rm -rf cannot delete the upmost directory level anymore on a Novell share
Message-ID: <20111021091056.GH13505@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4E9EE8CC DOT 5090806 AT lauterbach DOT com> <20111019154540 DOT GE22809 AT calimero DOT vinschen DOT de> <4E9EFE31 DOT 20809 AT lauterbach DOT com> <20111020092033 DOT GA5988 AT calimero DOT vinschen DOT de> <4EA00B16 DOT 1030400 AT lauterbach DOT com> <20111020130941 DOT GB13505 AT calimero DOT vinschen DOT de> <4EA028C9 DOT 1040300 AT lauterbach DOT com> <20111020172937 DOT GD13505 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20111020172937.GD13505@calimero.vinschen.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
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 Oct 20 19:29, Corinna Vinschen wrote:
> On Oct 20 15:57, Franz Sirl wrote:
> > Am 2011-10-20 15:09, schrieb Corinna Vinschen:
> > >As I wrote, it's not used, so even if it fails, it's worth a
> > >support case with Novell, but it doesn't mean we have to change
> > >Cygwin.
> > 
> > It fails with errorcode 0xc0000022, Access denied.
> 
> It might be worth a try to ask the Novell support why this occurs.
> This is a bug, IMHO.  Since Vista, this call should even be supported
> in the Win32 API, using the call
> 
>   FILE_BASIC_INFO fbi;
>   GetFileInformationByHandleEx (fhdl, FileBasicInfo, &fbi, sizeof fbi);
> 
> > >>>- NWFS only supports filenames which follow DOS conventions.  That is,
> > >>>   it does not support filenames with leading spaces or trailing dots and
> > >>>   spaces.  This is only checked for when generating filenames.
> > >>
> > >>Leading and trailing spaces seem to work, trailing dots fail with
> > >>"Permission denied".
> > >
> > >So we still have to assume that only DOS filenames work.
> > 
> > Hmm, I wonder if I should file at least a low priority enhancement
> > request for that.
> > 
> > >>>- NWFS does not support re-opening a file by handle, so it always has to
> > >>>   be re-opened by name.  The only difference here is how the
> > >>>   OBJECT_ATTRIBUTES is created, with a handle or with a name.
> > >>
> > >>I've worked with Novell to fix that one for NcFsd, will be in one of
> > >>the next releases (IR10 or IR11 I guess).
> > >
> > >Cool, but I think that NcFsd should still be subsumed under NWFS.
> > >The fact that re-opening doesn't quite work isn't such a big problem,
> > >and by using the OBJECT_ATTRIBUTES with a name we can support older
> > >versions of NcFsd as well.
> > 
> > Older versions of NcFsd have even more problems with Cygwin, so
> > supporting them doesn't really make sense. It only works reasonable
> > since this years June release. I would prefer to keep this code path
> > exercised :-).
> 
> Hmm, that should be possible.  But keep in mind that this does not
> have a better performance on all filesystems.
> 
> > >Are you ok if I send you an URL to a test DLL via PM for this issue?
> > >I would add the "handle NcFsd as NWFS" as well to this DLL, otherwise
> > >it would be identical to the latest snapshot, which should be available
> > >now, btw.
> > 
> > Sure, PM me the URL. [...]
> 
> Thanks, but not today anymore.

Rather than PM, I've just uploaded a snapshot which adds explicit NcFsd
support.  Please give it a try.  NcFsd is marked as having a buggy Query
FileBasicInformation support and as only supporting DOS filenames.  It
is not marked as having a buggy re-open file support and the comment
notes that this is supported starting with IR10, which isn't yet
released, AFAICS.

But there's one more change:  As you observed, NcFsd does not return a
STATUS_SHARING_VIOLATION when trying to open the top level directory for
DELETE, rather trying to set the delete disposition fails with
STATUS_CANNOT_DELETE.  When this error occurs, unlink_nt now also checks
for NcFsd, and if so, it tries delete-on-close as another method to
delete the file/directory.

This is just an experiment, so could you please take this snapshot and
test your fine testcase under strace on W7/NcFsd and send the strace here?

However,  IMHO this is a bug in NcFsd, just like the sharing violation
in NWFS.  Since NcFsd is activaly maintained, it might make sense for
you or any other NcFsd user to open a support case for this problem, just
like for the FileBasicInformation thingy.


Thanks,
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