find_first2 lookup behaviour on Samba with a case Insensitive FS - Samba

This is a discussion on find_first2 lookup behaviour on Samba with a case Insensitive FS - Samba ; Hi, I've been testing Samba 3.2 on a Case Insensitive (CI) XFS filesystem[1] with fs_capabilities set accordingly. Running into an interesting issue. Test Case: - map the CI XFS backed Samba share as z: - open a cmd window - ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: find_first2 lookup behaviour on Samba with a case Insensitive FS

  1. find_first2 lookup behaviour on Samba with a case Insensitive FS

    Hi,

    I've been testing Samba 3.2 on a Case Insensitive (CI) XFS filesystem[1]
    with fs_capabilities set accordingly. Running into an interesting issue.

    Test Case:
    - map the CI XFS backed Samba share as z:
    - open a cmd window
    - z:
    - mkdir lowercasedir
    - cd LOWERCASEDIR

    the prompt will then appear as z:\LOWERCASEDIR> rather than
    z:\lowercasedir> as shown on a stock Samba (no CI filesys) or NTFS.

    This is due to the name returned by a find_first2 SMB, which is obtained
    via unix_convert() where:

    - a stat of any case variant will succeed on a CI filesys
    -> the same name is returned

    - a stat of case variant will fail on case sensitive filesys
    -> falls through to perform a directory scan
    -> if the file is found during the directory scan, the file name
    as it is stored on disk is returned

    Aside from maybe confusing users, could this behaviour cause problems
    for applications?

    I'll post the CI XFS Samba patch after a cleanup and a few runs of
    James's RAW-BENCH-LOOKUP test.

    Cheers, Dave


    1. http://oss.sgi.com/archives/xfs/2008-05/msg00155.html


  2. Re: find_first2 lookup behaviour on Samba with a case Insensitive FS

    2008/5/28 David Disseldorp :
    > Hi,
    >
    > I've been testing Samba 3.2 on a Case Insensitive (CI) XFS filesystem[1]
    > with fs_capabilities set accordingly. Running into an interesting issue.
    >
    > Test Case:
    > - map the CI XFS backed Samba share as z:
    > - open a cmd window
    > - z:
    > - mkdir lowercasedir
    > - cd LOWERCASEDIR
    >
    > the prompt will then appear as z:\LOWERCASEDIR> rather than
    > z:\lowercasedir> as shown on a stock Samba (no CI filesys) or NTFS.
    >
    > This is due to the name returned by a find_first2 SMB, which is obtained
    > via unix_convert() where:
    >
    > - a stat of any case variant will succeed on a CI filesys
    > -> the same name is returned
    >
    > - a stat of case variant will fail on case sensitive filesys
    > -> falls through to perform a directory scan
    > -> if the file is found during the directory scan, the file name
    > as it is stored on disk is returned
    >
    > Aside from maybe confusing users, could this behaviour cause problems
    > for applications?


    Yes this causes problems for OSX 10.5. You need to return the
    canonical on-disk case in all cases. There is a patch in the Apple
    tree to do this for Darwin.




    IIRC, we also had some fixes to the rename path, when you rename a
    file to a case-variation of the existing name:



    > I'll post the CI XFS Samba patch after a cleanup and a few runs of
    > James's RAW-BENCH-LOOKUP test.


    Was there much to do? I thought I had pushed all the HFS+
    case-insensitivity patches ...

    --
    James Peach | jorgar@gmail.com


  3. Re: find_first2 lookup behaviour on Samba with a case Insensitive FS

    On Wed, May 28, 2008 at 09:09:32PM -0700, James Peach wrote:
    >
    > Yes this causes problems for OSX 10.5. You need to return the
    > canonical on-disk case in all cases. There is a patch in the Apple
    > tree to do this for Darwin.
    >
    >
    >


    For SMB_VFS_GET_PRESERVED_NAME, this really needs to take
    a char ** that is allocated on return. Remember pstrings no
    longer exist in 3.2.

    What does the underlying interface into the OS look like ?
    Does it allocate, or do you pass in a max length ?

    Jeremy.


  4. Re: find_first2 lookup behaviour on Samba with a case Insensitive FS

    On Wed, 28 May 2008 21:09:32 -0700
    "James Peach" wrote:

    > > Aside from maybe confusing users, could this behaviour cause problems
    > > for applications?

    >
    > Yes this causes problems for OSX 10.5. You need to return the
    > canonical on-disk case in all cases. There is a patch in the Apple
    > tree to do this for Darwin.


    You mean problems for the OSX 10.5 CIFS client?

    >
    >
    >


    Hopefully the lookup in GET_PRESERVED_NAME() will not hurt performance
    too much. A kernel get_preserved call would be handy.

    > IIRC, we also had some fixes to the rename path, when you rename a
    > file to a case-variation of the existing name:
    >
    > <http://www.opensource.apple.com/darw...tive-filenames

    Thanks

    > Was there much to do? I thought I had pushed all the HFS+
    > case-insensitivity patches ...


    Just had to add the XFS ioctl call to statvfs.

    Cheers, Dave


  5. Re: find_first2 lookup behaviour on Samba with a case Insensitive FS

    2008/5/28 Jeremy Allison :
    > On Wed, May 28, 2008 at 09:09:32PM -0700, James Peach wrote:
    >>
    >> Yes this causes problems for OSX 10.5. You need to return the
    >> canonical on-disk case in all cases. There is a patch in the Apple
    >> tree to do this for Darwin.
    >>
    >>
    >>

    >
    > For SMB_VFS_GET_PRESERVED_NAME, this really needs to take
    > a char ** that is allocated on return. Remember pstrings no
    > longer exist in 3.2.


    yep, this patch is against 3.0.28.

    > What does the underlying interface into the OS look like ?




    You use getattrlist(2) to get the ATTR_CMN_NAME attribute, which gives
    you the on-disk file name.

    > Does it allocate, or do you pass in a max length ?


    You pass a buffer os size NAME_MAX (255 bytes).

    --
    James Peach | jorgar@gmail.com


  6. Re: find_first2 lookup behaviour on Samba with a case Insensitive FS

    2008/5/28 David Disseldorp :
    > On Wed, 28 May 2008 21:09:32 -0700
    > "James Peach" wrote:
    >
    >> > Aside from maybe confusing users, could this behaviour cause problems
    >> > for applications?

    >>
    >> Yes this causes problems for OSX 10.5. You need to return the
    >> canonical on-disk case in all cases. There is a patch in the Apple
    >> tree to do this for Darwin.

    >
    > You mean problems for the OSX 10.5 CIFS client?


    Yes.

    >>
    >>

    >
    > Hopefully the lookup in GET_PRESERVED_NAME() will not hurt performance
    > too much. A kernel get_preserved call would be handy.


    The performance impact depends on the kernel interface you use to get
    the preserved name. For us it's an extra system call on every lookup.
    Not ideal, but necessary.

    --
    James Peach | jorgar@gmail.com


  7. Re: find_first2 lookup behaviour on Samba with a case Insensitive FS

    On Wed, 28 May 2008 23:07:22 -0700
    "James Peach" wrote:

    >


    So SMB_VFS_GET_PRESERVED_NAME should only return the preserved name of
    the last component?

    If so, could there be situations where preserved name of an entire path
    needs to be obtained, or would it be the callers responsibility to iterate?

    Cheers, Dave


  8. Re: find_first2 lookup behaviour on Samba with a case Insensitive FS

    2008/5/29 David Disseldorp :
    > On Wed, 28 May 2008 23:07:22 -0700
    > "James Peach" wrote:
    >
    >>

    >
    > So SMB_VFS_GET_PRESERVED_NAME should only return the preserved name of
    > the last component?


    Yes. Protocol info levels that return the filename only return the
    last component.

    > If so, could there be situations where preserved name of an entire path
    > needs to be obtained, or would it be the callers responsibility to iterate?


    If you think about how a kernel filesystem builds its file hierarchy,
    it only deals with one level at a time. This means that it always has
    the correct case.

    --
    James Peach | jorgar@gmail.com


+ Reply to Thread