This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

cygwin coreutils-6.9-5


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forwarding this conversation from the cygwin lists, as it provides some
useful information on the recent topic of case insensitivity.

According to Corinna Vinschen on 8/22/2007 2:30 AM:
> On Aug 21 15:47, Eric Blake wrote:
>> According to Reini Urban on 8/21/2007 3:26 PM:
>>>> This is a minor patch release.  It attempts to add some
>>>> case-insensitivity
>>>> smarts to mv, cp, and install.  In other words, 'mv a A' should now cause
>>>> the file to be renamed, rather than reporting an error, if 'a' and 'A'
>>>> happen to be case-insensitive synonyms for the same file.
>>> Great, thanks!
>>> Are you planning to submit the patch upstream?
>> My patch turned out to be more invasive than I would have liked.  Also,
>> there have been upstream discussions on the problem (since Mac HFS, and
>> even Linux mounts to FAT, are also affected).  The biggest problem is that
>> my patch uses <sys/cygwin.h>, which is NOT portable - there really is no
>> good way (at the moment) across all three platforms to tell if a directory
>> is case-insensitive.  It would be nice if there was a pathconf(directory,
>> _PC_CASE_INSENSITIVE) that could quickly be queried to see if
>> case-insensitivity is even worth worrying about for the directory in
>> question.  Also brought up on the coreutils list is the problem that the
>> kernel's notion of file system case-insensitivity may be different from
>> the current locale's definition of case-insensitivity (not really an issue
>> for cygwin so long as we don't really support locales, but definitely an
>> issue for Linux and Mac).
> 
> Dunno if that's helpful for the discussion, but on second (third?)
> thought, *maybe* it's not a boundless good idea to manage
> case-insensitivity generically in coreutils without explicit OS support
> like the above _PC_CASE_INSENSITIVE flag for pathconf.
> 
> First, a simple test with FAT on Linux shows that case-insensitivity of
> the underlying file system is not necessarily handled correctly by the
> OS.  On Linux, rename("a", "A") is a no-op on FAT, according to the
> POSIX rule that rename is a no-op if src and dest are hardlinks to the
> same file(*).  To fix this behaviour in coreutils, it would be necessary
> to *know* that the underlying FS is case-insensitive (is there any flag
> to exchange between Linux kernel and FS driver?  I don't know), and to
> rename the file in two steps (a -> $tmpname -> A).

I don't know the Linux kernel well enough to know where to suggest that
Linux change behavior to allow case renaming, rather than requiring an
intermediate file.  I reiterate my argument that since POSIX file systems
are case sensitive, the behavior of rename(2) on case-insensitive systems
is not specified by POSIX, therefore we are free to give it case-changing
semantics rather than being a no-op; but someone would have to implement it.

> 
> Second, even if a FS appears case-insensitive, it isn't necessarily so.
> NTFS is case-sensitive.  The case-insensitivity is actually handled by
> the Windows kernel.  Basically, a flag in calls to functions taking a
> filename as parameter is all it takes to make a function call
> case-insensitive or not(**).  The Win32 calls all use case-insensitivity.
> Some are switchable to work case-sensitive, but it's not of much help
> since other calls are always case-insensitive.  Cygwin handles all file
> system calls case-insensitive, too.  So far.
> 
> So, in the Linux/FAT example we have a case-sensitive OS with a
> case-insensitive FS, with Win32/NTFS (Cygwin/NTFS) we have a
> case-insensitive OS with a case-sensitive FS.  While the NT kernel can
> return information about the case-sensitivity of the underlying FS (***)
> (****), I don't know about other OSes.
> 
> So we're back to fpathconf(_PC_CASE_INSENSITIVE): It appears that
> case-insensitive operation on the POSIX application level depends on
> such a flag.  I'm also planning to allow case-sensitive operation on
> NTFS in Cygwin at one point, which would make this flag necessary as
> well.  I don't think it would ever become part of the POSIX standard,
> though.

If _PC_CASE_INSENSITIVE ever did get standardized, it would be merely to
guarantee existence of the flag, with the caveat that in POSIX it always
returns false.  But since POSIX does allow implementations to add _PC_*
flags to pathconf as extensions, I see no harm in implementing it even
without specification.

> 
> 
> Corinna
> 
> 
> 
> (*)   In theory, Cygwin's rename could do the same and still move within
>       POSIX rules, no matter how frustrating this behaviour might be.
> 
> (**)  Plus a registry setting since XP.
> 
> (***) See the FILE_CASE_SENSITIVE_SEARCH file system flag:
>       http://cygwin.com/ml/cygwin/2007-08/msg00013.html
> 
> (****) As far as the underlying FS returns the correct flags, of course.
> 

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGzDA/84KuGfSFAYARAhZwAKCmadeTDvareHLpOZLjQqzbpV8J1wCgrEl6
gQaqqljdi5osXhoq1pWVjPI=
=RYRd
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]