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

[Franz Sirl]

Am 2011-10-20 15:09, schrieb Corinna Vinschen:
> On Oct 20 13:50, Franz Sirl wrote:
>> Am 2011-10-20 11:20, schrieb Corinna Vinschen:
>>> On Oct 19 18:43, Franz Sirl wrote:
>>>> 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.
>>
>> I think that still fails with NcFsd, I'll check it.
>
> 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.

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

>> $ mount
>> F: on /cygdrive/f type ncfsd (binary,posix=0,user,noumount,auto)
>
> Ok, so it's not subsumed under any other filesystem.  I'll change that
> in CVS to handle NcFsd identical to NWFS.
>
>> $ /usr/lib/csih/getVolInfo /cygdrive/j
>> Device Type        : 7
>> Characteristics    : 30
>> Volume Name        :<VOL_DEVEL>
>> Serial Number      : 1549160268
>> Max Filenamelength : 255
>> Filesystemname     :<NcFsd>
>> Flags              : a2
>>    FILE_CASE_SENSITIVE_SEARCH  : FALSE
>>    FILE_CASE_PRESERVED_NAMES   : TRUE
>>    FILE_UNICODE_ON_DISK        : FALSE
>>    FILE_PERSISTENT_ACLS        : FALSE
>>    FILE_FILE_COMPRESSION       : FALSE
>>    FILE_VOLUME_QUOTAS          : TRUE
>>    FILE_SUPPORTS_SPARSE_FILES  : FALSE
>>    FILE_SUPPORTS_REPARSE_POINTS: TRUE
>>    FILE_SUPPORTS_REMOTE_STORAGE: FALSE
>>    FILE_VOLUME_IS_COMPRESSED   : FALSE
>>    FILE_SUPPORTS_OBJECT_IDS    : FALSE
>>    FILE_SUPPORTS_ENCRYPTION    : FALSE
>>    FILE_NAMED_STREAMS          : FALSE
>>    FILE_READ_ONLY_VOLUME       : FALSE
>>    FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
>>    FILE_SUPPORTS_TRANSACTIONS  : FALSE
>
> Thanks.
>
>> The rest of your questions I will answer as soon as the new snapshot
>> is available.
>
> 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. I'll try the new snapshot anyway.

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