Mail Archives: cygwin/2011/10/21/10:58:44
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
- Raw text -