From: SourceForge.net <no...@so...> - 2007-09-29 22:20:06
|
Bugs item #1804659, was opened at 2007-09-29 09:27 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1804659&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: msys Group: Known Feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: sg_ (sg_) Assigned to: Cesar Strauss (cstrauss) Summary: diff sensitive to case of filenames Initial Comment: Hello, The diff in the latest diffutils-2.8.7-MSYS-1.0.11-snapshot.tar.bz2 is sensitive to the case of filenames: $ mkdir a $ mkdir b $ cd a $ echo hello > foo $ cp foo ../b/FOO $ cd .. $ diff -sqr a b Only in b: FOO Only in a: foo $ cp -i a/foo b cp: overwrite `b/foo'? n Thanks, ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2007-09-29 22:20 Message: Logged In: YES user_id=823908 Originator: NO For two files, living in the same directory on a case insensitive file system, it is an incontrovertible truth that `foo == FOO'; any tool which believes otherwise, is broken IMO. On a "case insensitive but case retentive" file system, such as Woe32, any tool asked to stat, or to open "foo" shouldn't care if the retained name is "FOO", for `foo == FOO'; the request should succeed. All of the "native" tools will respect this; ours should too. If they do not, then IMO, they are broken. A different case arises, with a "case sensitive" file system remotely mounted to a system whose "native" file system is "case insensitive". In this case, `foo == FOO' becomes an incontrovertible falsehood. Ideally, the tool should recognise this special case, and act accordingly. If this is not practical, then I firmly believe that the fallback mechanism should respect the "native" host conventions. As I've stated in mailing list posts, any well designed package should respect the naming conventions of the more restrictive file system case. Any package which relies on `foo != FOO' is broken, and should be fixed; don't smack the tool, because the package you want to use it on is badly behaved. IMO, this is a legitimate bug report; `diff' is broken, and should be fixed. If a need is felt to retain the misbehaving variant, then it should be a separate program, provided as we now provide `csmake' as an alternative to `make', so `csdiff' for a `diff' which believes the `foo != FOO' falsehood. BTW, an interesting case, which you haven't considered: if your samba mounted linux hosted directory is your source directory, and you perform a VPATH make, hosted on your Woe32 box, can you select between the "foo" and "FOO" sources with standard "case insensitive" `make', or do you need `csmake'? This is the only use-case where I can see a possible practical reason to use `csmake', and as I've already stated, I consider it to be a broken use-case. ---------------------------------------------------------------------- Comment By: sg_ (sg_) Date: 2007-09-29 20:19 Message: Logged In: YES user_id=1901579 Originator: YES I ran some experiments that indicate that having a diff that is insensitive to the case of file-names should not cause problems: Set Up: ------ A) /n/Cell is a samba-mount. I went into Linux and created identical files in that directory foo and foO. B) On my PC, I have MSYS' case sensitive diff and also UnxUtils' case insensitive diff named as uudiff. /n/Cell$ which diff /bin/diff /n/Cell$ diff --version diff (GNU diffutils) 2.8.7 Written by Paul Eggert, Mike Haertel, David Hayes, Richard Stallman, and Len Tower. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /n/Cell$ which uudiff /c/opt/uu/usr/local/wbin/uudiff /n/Cell$ uudiff --version diff - GNU diffutils version 2.7 /n/Cell$ Experiment done on Windows XP laptop: ------------------------------------ /n/Cell$ ls f* foO foo /n/Cell$ diff -s foo foO Files foo and foO are identical /n/Cell$ uudiff -s foo foO Files foo and foO are identical /n/Cell$ mkdir a /n/Cell$ mkdir b /n/Cell$ cd a /n/Cell/a$ echo hello > foo /n/Cell/a$ cp foo ../b/FOO /n/Cell/a$ cd .. /n/Cell$ diff -sqr a b Only in b: FOO Only in a: foo /n/Cell$ uudiff -sqr a b Files a\foo and b\FOO are identical Then I went back to linux: diff -sqr a b reports a/foo and b/FOO as "Only in " files. So there should be no problem with deploying a diff that is case insensitive -- the Operating System takes care of such issues transparently. And having a case sensitive diff in a case insensitive OS prevents the case insensitive OS from doing its job. Thanks, --Suresh ---------------------------------------------------------------------- Comment By: sg_ (sg_) Date: 2007-09-29 15:42 Message: Logged In: YES user_id=1901579 Originator: YES On the MinGW mailing list, in connection with case-sensitive and case-in-sensitive make, Keith Marshall wrote: > [...] I haven't figured out how to cross-compile MSYS components on a > GNU/Linux build machine; could you please prepare an alternative build with > `--disable-case-insensitive-file-system', for the lunatics who wish to stay > in the asylum? I'm open to suggestions as to what this should be called; I > still believe that `--enable-case-insensitive-file-system' should remain > the default deliverable, and this alternative optional. Refer: http://sourceforge.net/mailarchive/message.php?msg_name=1191078298.4844.223.camel%40localhost ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2007-09-29 14:07 Message: Logged In: YES user_id=15438 Originator: NO Cesar, I consider this correct behavior. File named foo is different than file named FOO. Changing this may break other things such as cvs so if it is decided to make the switch thorough regression testing with utilities that use diff need to be considered. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1804659&group_id=2435 |