Re: [fuse-devel] File system with case insensitive names [PATCH]

[Jean-Pierre A. <jea...@wa...>]

Hi again,

Well, I should have checked first...

Jean-Pierre André wrote:
> Hi,
>
> Thank you Miklos, for your view on this.
>
> I agree for the need for consistency checks, and hope
> your suggestion to check parent directory is easy to
> implement.  Debabrata ?
>
> I have had in the past some disappointment with cacheing
> in fuse, so I have disabled it, and done the cacheing in the
> file system, so this is not of real concern to me.
>
> And I would think that the unwanted canonicalization is
> tolerable, so, if this is not improvable at a reasonable cost,
> I would be satisfied with it.
>    

Having cd'ed to a directory foo in a window, and to FOO
in another (the stored name being foo), I get the expected
variant when pwd'ing in each window, so the current
directory name must be stored elsewhere.

Is the canonicalization related to cacheing, or am I missing
something ?

Regards

Jean-Pierre


> Regards
>
> Jean-Pierre
>
>
> Miklos Szeredi wrote:
>    
>> Jean-Pierre André<jea...@wa...>   writes:
>>
>>
>>      
>>> Hi,
>>>
>>> Well, I posted this earlier, but because of the holiday season and more
>>> urgent matters, it did not arouse much interest.
>>>
>>> However case insensitivity is frequently asked by users of ntfs-3g who have
>>> compatibility concerns with some obscure OS, and I have myself a poor
>>> knowledge of the fuse internals, so I would like to ask again whether this
>>> proposed patch is safe, and whether there is any reason for not including
>>> some option for it (or something similar) in future releases ?
>>>
>>> Regards
>>>
>>> Jean-Pierre
>>>
>>> Jean-Pierre André wrote:
>>>
>>>        
>>>> Hi All,
>>>>
>>>>
>>>> Debabrata Banerjee wrote:
>>>>
>>>>          
>>>>> 6th time's the charm. See any problems with this?
>>>>>
>>>>> --- fuse-2.6.32.o/dir.c    2009-12-02 22:51:21.000000000 -0500
>>>>> +++ fuse-2.6.32/dir.c    2011-07-12 15:19:52.061492619 -0400
>>>>> @@ -243,11 +243,16 @@
>>>>>     {
>>>>>         struct dentry *alias = d_find_alias(inode);
>>>>>         if (alias&&    !(alias->d_flags&    DCACHE_DISCONNECTED)) {
>>>>> +          /* there can only be one dentry for a directory, so
>>>>> return the old one
>>>>> if it is different */
>>>>> +        if(alias != entry) {
>>>>>
>>>>>            
>> This condition is always going to be true since "entry" is a newly
>> allocated dentry and is guaranteed to be not yet connected to any inode.
>>
>>
>>      
>>>>> +             d_invalidate(entry);
>>>>> +             iput(inode);
>>>>> +             return alias;
>>>>>
>>>>>            
>> This basically says: wherever "inode" can be found in the cache we will
>> jump there and continue the lookup.  Imagine what happens if this inode
>> is the parent directory of the lookup.
>>
>> Of course we can allow "alias" to be used only if it has the same parent
>> as "entry" and most of the problems go away.
>>
>> Two lesser issues:
>>
>>    - caching: only the first name looked up will be cached.  E.g. a
>>      directory is looked up by the name of "FoO" and then looked up a
>>      thousand times by the name of "foo" then each of those will generate
>>      a LOOKUP request, which will be orders of magnitude slower than the
>>      cached lookup.
>>
>>    - canonicalization: the name by which it was looked up first will be
>>      the canonical name (displayed in cwd, etc).  Not sure how this is
>>      handled in CIFS and friends.
>>
>>
>>      
>>>>> +        }
>>>>> +
>>>>>             /* This tries to shrink the subtree below alias */
>>>>>             fuse_invalidate_entry(alias);
>>>>>             dput(alias);
>>>>> -        if (!list_empty(&inode->i_dentry))
>>>>> -            return ERR_PTR(-EBUSY);
>>>>>         } else {
>>>>>             dput(alias);
>>>>>         }
>>>>>
>>>>>
>>>>>            
>>>> My tests of this patch were successful, thank you
>>>> Debabrata for your contribution.
>>>>
>>>> Does anybody have any remarks ?
>>>>
>>>> And, Miklos, is this acceptable for inclusion in
>>>> future versions, maybe under some condition to be
>>>> defined in an option or init callback ?
>>>>
>>>>          
>> Yes, it should be controlled by an explicit flag negotiated in the INIT
>> sequence.
>>
>> Thanks,
>> Miklos
>>
>>
>>      
>    

-- 
JP André
email jea...@wa...