This is the mail archive of the
mailing list for the Cygwin project.
Re: rm -rf cannot delete the upmost directory level anymore on a Novell share
Am 2011-10-21 11:10, schrieb Corinna Vinschen:
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
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
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
- 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
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
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
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
FileBasicInformation, isn't buggy anymore, see above.
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
rm-8.4: cannot remove `lev1': Directory not empty
The corresponding strace looks like:
242 240405 [main] rm-8.4 6088 unlink_nt: Trying to delete
\??\J:\FRA\test_rm_rf\lev1, isdir = 1
1004 241409 [main] rm-8.4 6088 unlink_nt: Setting delete disposition
on \??\J:\FRA\test_rm_rf\lev1 failed, status = 0xC0000121
263 241672 [main] rm-8.4 6088 unlink_nt: Cannot delete
\??\J:\FRA\test_rm_rf\lev1, try delete-on-close
1272 242944 [main] rm-8.4 6088 unlink_nt: \??\J:\FRA\test_rm_rf\lev1,
return status = 0x0
1754 244698 [main] rm-8.4 6088 seterrno_from_nt_status:
status 0xC0000101 -> windows error 145
266 244964 [main] rm-8.4 6088 geterrno_from_win_error: windows error
145 == errno 90
237 245201 [main] rm-8.4 6088 rmdir: -1 = rmdir (/test_rm_rf/lev1)
I guess this error is from fhandler_disk_file::rmdir().
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.
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):
1. CreateFile(FILE_READ_ATTRIBUTES | DELETE, FILE_SHARE_DELETE) should
not succeed, but fail with STATUS_SHARING_VIOLATION
2. CreateFile(FILE_READ_ATTRIBUTES | DELETE, FILE_SHARE_READ |
FILE_SHARE_WRITE | FILE_SHARE_DELETE) should succeed and the following
SetFileInformationByHandle(DELETE) should succeed too
This is what I came up with after looking what happens against a
samba-3.4.3 and WinXP share. Does that sound right?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple