On Aug 21 15:47, Eric Blake wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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). 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. 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. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/