On Fri, Sep 26, 2014 at 10:03:50PM +0200, Olaf Weber wrote: > On 26-09-14 21:46, Jeremy Allison wrote: > >On Fri, Sep 26, 2014 at 09:37:11PM +0200, Olaf Weber wrote: > >> > >>My argument against "mount time case-insensitivity" and for "mkfs > >>time case-insensitivity" is related to switching from the > >>case-sensitive domain to the case-insensitive one. > >> > >>For case-sensitive, from "README" to "readme" there are 64 different > >>possible filenames. Let's say you create 63 out of these 64. Now > >>remount the filesystem case-insensitive, and try to open by the 64th > >>version of "readme". It is not an exact match for any of the 63 > >>candidate files, and a case-insensitive match to all 63 candidate > >>files. Which of these 63 files should be opened, and why that one in > >>particular? > > > >I'm ok with "mkfs time case-insensitivity" - really ! > >Most of my OEMs would set that and claim victory (few > >of them care much about NFS semantics :-). > > I'd say you can have CIFS-style case-insensitive semantics or > NFS-style case-sensitive semantics, but not both. Note the NFSv4 specs do claim to allow case insensitivity. No idea how well clients deal with it. I think rfc3530bis has the most up to date language on NFSv4 internationalization issues: http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-33 (One nit in the current knfsd: the server doesn't correctly report the case_insensitive attribute. If it had some flag it could check in the filesystem's superblock then it could do that right instead of just assuming 0 as it currently does (see FATTR4_WORD0_CASE_INSENSITIVE in fs/nfsd/nfs4xdr.c:nfsd4_encode_fattr).) --b. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
