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

[Franz Sirl]

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