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


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
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);

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.



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

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 anyway:


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: /ext/build/netrel/src/cygwin-snapshot-20111021-1/winsup/cygwin/fhandler_disk_file.cc:1735 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?

Franz.


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


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