This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rm -rf cannot delete the upmost directory level anymore on a Novell share

On Oct 21 16:58, Franz Sirl wrote:
> Am 2011-10-21 11:10, schrieb Corinna Vinschen:
> >>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);
> This succeeds?? Arrgh, looking at my testcase again, I see that I
> only used NtOpenFile(WRITE_ATTRIBUTES | DELETE). I reused my code to
> test the read-only file deletion, but forgot to change this, sorry.
> As soon as I added READ_ATTRIBUTES, the testcase using
> NtQueryInformationFile(FileBasicInformation) succeeded.

Ok, I change that in Cygwin for completeness.  It's still not used,
but it's good to know.

> >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?
> The functionality works (directory is deleted), but an error is
> reported anyway:
> rm-8.4: cannot remove `lev1': Directory not empty
> The corresponding strace looks like:
> [...]
>  1754  244698 [main] rm-8.4 6088 seterrno_from_nt_status: /ext/build/netrel/src/cygwin-snapshot-20111021-1/winsup/cygwin/
> status 0xC0000101 -> windows error 145

Ouch, yes, that makes sense.  The test for success should only be
performed for samba shares.  I'll fix that.

> >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
> I will create a support case with Novell. To make my understanding
> clear, I think there are actually 2 problems here (Win32 calls for
> illustration, assuming the directory is already opened):

  0. The directory has been opened with all sharing modes allowed "elsewhere".

> should not succeed, but fail with STATUS_SHARING_VIOLATION

I didn't see a full strace from W7.  Did you check that this doesn't
happen anyway?

> FILE_SHARE_WRITE | FILE_SHARE_DELETE) should succeed and the

... and that therefore this second NtCreateFile works as expected?

> following SetFileInformationByHandle(DELETE) should succeed too

Yes.  It should not be required to open the dir with delete-on-close,
just because it's still open elsewhere.  After all, the meaning of
"setting the delete disposition" is not that the dir has to be deleted
immediately if it's still in use.

> This is what I came up with after looking what happens against a
> samba-3.4.3 and WinXP share. Does that sound right?

More or less, yes.  I'll check in my changes shortly.


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

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]