X-Spam-Check-By: sourceware.org Message-ID: <46CC3040.2000908@byu.net> Date: Wed, 22 Aug 2007 06:46:56 -0600 From: Eric Blake User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: cygwin AT cygwin DOT com, bug-coreutils Subject: cygwin coreutils-6.9-5 References: <46CB58A1 DOT 3040202 AT x-ray DOT at> <46CB5D57 DOT 5080401 AT byu DOT net> <20070822083015 DOT GA13475 AT calimero DOT vinschen DOT de> In-Reply-To: <20070822083015.GA13475@calimero.vinschen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com -----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 , 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 AT byu DOT 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/