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 19 18:43, Franz Sirl wrote:
> Am 2011-10-19 17:45, schrieb Corinna Vinschen:
> >On Oct 19 17:12, Franz Sirl wrote:
> >>sometime between coreutils-7.0 and coreutils-8.4 (sorry, I don't
> >>have any other in between versions anymore) this simple command
> >>started to fail:
> >>
> >># mkdir -p lev1/lev2/lev3
> >># rm -rfv lev1
> >>removed directory: `lev1/lev2/lev3'
> >>removed directory: `lev1/lev2'
> >>rm: cannot remove `lev1': Device or resource busy
> >>
> >>Tested with coreutils-8.10 and cygwin1.dll from the 20111017
> >>snapshot, as the cygwin1.dll didn't make any difference for the
> >>problem.
> >>
> >>If I just use rm.exe from coreutils-7.0 everything starts to work as
> >>expected again:
> >>
> >># mkdir -p lev1/lev2/lev3
> >># rm -rfv lev1
> >>removed directory: `lev1/lev2/lev3'
> >>removed directory: `lev1/lev2'
> >>removed directory: `lev1'
> >
> >The problem is, it works fine on local and remote NTFS, as well as on
> >Samba.  Since the number of open handles doesn't depend on the underlying
> >filesystem, why should it fail for NWFS?
> True. But on the other hand NWFS and NcFsd exercise a lot of pathes
> in the Cygwin sourcecode that aren't usually used.

Not really a lot.  NWFS is known to have three problems:

- The NtQueryInformationFile(FileBasicInformation) call fails.  This
  call is only used in circumstance which don't affect NWFS.

- 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.

- 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.

> Even between NWFS
> on XP and NcFsd on Win7 there are differences, because fs.is_nwfs()
> doesn't trigger on Win7 with the Novell Client (the filesystem name
> is different).

I don't have access to the various filesystems, so I depend on users
giving me the required information about exotic filesystems if they wish
that it will be supported.  For "NcFsd", can you please post the output
of the `/usr/lib/csih/getVolInfo <path_to_fs>' command?  Also, if you
haven't already done so, plase create a Cygwin mount point pointing to
some path on the filesystems and paste the output of the command
`mount'.  This shows under which filesystem NcFsd is subsumed right now.

> >>   216  174576 [main] rm-8.10 336 unlink_nt: Opening file for delete
> >>failed, status = 0xC0000043
> >>   240  174816 [main] rm-8.10 336 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/
> >>status 0xC0000043 ->  windows error 32
> >
> >That's a sharing violation.  Where's the difference to the strace
> >output with the exact same Cygwin DLL and rm from coreutils 7?
> Hmm, I just see that on Win7 the errorcode for unlink_nt is
> different, for completeness:
>  2046  158907 [main] rm-8.10 2940 unlink_nt: Setting delete
> disposition failed, status = 0xC0000121
>   594  159501 [main] rm-8.10 2940 seterrno_from_nt_status: /netrel/src/cygwin-snapshot-20111017-1/winsup/cygwin/
> status 0xC0000121 -> windows error 5
>   193  159694 [main] rm-8.10 2940 geterrno_from_win_error: windows
> error 5 == errno 13

The OS returns STATUS_CANNOT_DELETE here.  Which is very helpful, of
course, since it does nothing to tell the developer *why* it can't be

If we could recognize NcFsd (see my requests above), what we could do at
this point is to try "delete-on-close".  The code for that exists in
unlink_nt and it's used exactly in the case where we get the error code
STATUS_CANNOT_DELETE.  However, due to a problem with remote shares in
this context, Cygwin only tries that with local filesystems right now.

> The strace from rm-7.0 on XP looks like this:
> [...]

> So with rm-7.0 it doesn't try to use unlink_nt() and also rm-8.10
> doesn't try to use unlink_nt() on a samba-3.4.3 share. That's why it
> looked a bit suspicious to me.

You misinterpreted the strace output.  unlink_nt only generates strace
output if something has gone wrong.  It's called, it just doesn't print
anything in case of success.

Hmm, puzzeling.  So when you use the NcFsd driver you can open the file
but trying to set the delete dispostion fails with STATUS_CANNOT_DELETE,
and if you're accessing it via SMB and so is recognized as NWFS, the
open for delete already fails with a STATUS_ACCESS_VIOLATION.

In theory, the STATUS_ACCESS_VIOLATION should not be Cygwin, and not
rm itself.  In the strace output from rm 7.0 you'll see this:

  fhandler_base::open: 0 = NtCreateFile (0x704, 80100000, \??\J:\FRA\test_rm_rf\lev1, io, NULL, 0, 7, 1, 4020, NULL, 0)
  open: 3 = open (/test_rm_rf/lev1/lev2/.., 0x8000)
  rmdir: 0 = rmdir (/test_rm_rf/lev1)

Note the absence of a "close (3)" here.  So rm has an open file
descriptor to /test_rm_rf/lev1, but the rmdir succeeds.  That's how it
should be, in fact.  Cygwin opens files always with all sharing flags
set, so a file opened by a Cygwin process should not result in a sharing
violation in another open call.  The exception is the first NtOpenFile
in unlink_nt, which opens the file with FILE_SHARE_DELETE only to find
out if the file has an open handle somewhere else.  In that case it gets
a STATUS_SHARING_VIOLATION, the next NtOpenFile will open the file with
all sharing flags set, and unlink_nt will try to delete the file or to
rename it, or to move it to the recycle bin, dependent on its path.

Anyway, we're not a single step further.  First of all, please send
the FS information I requested above.  Next, please generate straces
of rm 7.0 and rm 8.4 for this scenario, both on the same machine
and running the latest Cygwin developer snapshot and send the full
straces here.


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]