Bug Emacs 21.3: write-file downcasing

Bug Emacs 21.3: write-file downcasing

[Dhruva Krishnamurthy]

Hello,
 I am using the following GNU Emacs version from CVS.
Emacs version:
GNU Emacs 21.3.50.1 (i386-mingw-nt5.0.2195) of 2003-02-05 on WOLFDEI
- When I use the command 'write-file', the filename becomes lowercase.
  After saving, the file along with the path is shown in lower case in
  the minibuffer.

Ex:
(write-file "Dummy.cpp")
=> saved as "dummy.cpp".
Though Win is a case insensitive platform, it makes the file names no so
user freindly when everything is in lower case. This is more visible when
you have long names
(ex:GraphicsDisplayUtilities.cpp=>graphicdisplayutilities.cpp)

This does not happen in the latest Pretest version:
GNU Emacs 21.2.95.1 (i386-mingw-nt5.0.2195) of 2003-02-07 on WOLFDEI

Approx problem area:
(set-visited-file-name "Dummy.cpp")
(buffer-file-name)=>"dummy.cpp"
In the file "files.el" and function 'set-visited-file-name', only for VMS
the downcasing is done. I do not know why this is happening.

Another minor problem:
In the DOTEMACS if you have,
(require 'cua)
(CUA-mode t)
(pc-selection-mode t)
The CTRL button just stops working. This is in the CVS version only and
not in Pretest version.

with regards,
dhruva
-- 
Dhruva Krishnamurthy
Home: http://www32.brinkster.com/schemer/

Re: Bug Emacs 21.3: write-file downcasing

[Juanma Barranquero]

On Fri, 07 Feb 2003 11:08:06 +0530, "Dhruva Krishnamurthy" <seagull@fastmail.fm> wrote:

> Approx problem area:
> (set-visited-file-name "Dummy.cpp")
> (buffer-file-name)=>"dummy.cpp"
> In the file "files.el" and function 'set-visited-file-name', only for VMS
> the downcasing is done. I do not know why this is happening.

The troble is, I suppose, related to this patch:

2002-11-27  Jason Rumney  <jasonr@gnu.org>

        * files.el (file-truename): Canonicalize non-existent names on w32.

which tried to solve the following problem:

(file-truename "C:/temp/a_file")  => "C:/temp/a_file"   ; a_file does not exist
(file-truename "C:/temp/a_file")  => "c:/temp/a_file"   ; a_file exists
(file-truename "/temp/a_file2")   => "/temp/a_file"     ; a_file does not exist
(file-truename "/temp/a_file")    => "c:/temp_a_file"   ; a_file exists

Jason and I were discussing it a few days ago because the current behavior
(after the patch) is murder for people who uses Java and back-port their
code to non-Windows platforms.

The only fix I can think of seems like a hack, because it would be
necessary to do some sort of canonicalization (to get the drive, for
example, which presumibly depends on the "process' default drive"), but
preserve as much of the user-supplied filename as posible.

                                                           /L/e/k/t/u

Re: Bug Emacs 21.3: write-file downcasing

[Eli Zaretskii]

> Date: Fri, 07 Feb 2003 09:07:44 +0100
> From: Juanma Barranquero <lektu@terra.es>
> 
> The only fix I can think of seems like a hack, because it would be
> necessary to do some sort of canonicalization (to get the drive, for
> example, which presumibly depends on the "process' default drive"), but
> preserve as much of the user-supplied filename as posible.

Perhaps we should discuss the original problem and see if there are
any alternative solutions.  What was the problem that caused the
change in file-truename?

Re: Bug Emacs 21.3: write-file downcasing

[Juanma Barranquero]

On Fri, 07 Feb 2003 17:23:12 +0200, "Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> What was the problem that caused the change in file-truename?

My e-mails to Jason were as follows:

> Hi.
> 
> I'm investigating this:
> 
> > 2001-11-08  Andrew.Maguire@Smallworld.co.uk (Andrew Maguire)  gnu.emacs.bug
> >   (file-truename "C:/temp/a_file")
> >   returns "C:/temp/a_file" if the file does not exist and
> >   "c:/temp/a_file" if it does.
> 
> I'm not convinced this is a bug :)
> 
> If the file does not exist, the argument is returned unmodified.
> 
> OTOH, if the file does exist, eventually normalize_filename (in w32.c)
> gets called, which returns the path and name exactly as it exists in
> the filesystem, but purposefully downcases the drive letter, according
> to this changelog entry:
> 
> > 1996-07-03  Andrew Innes  <andrewi@harlequin.co.uk>
> > 
> >         * nt.c (normalize_filename): Always lower-case drive letters, even
> >         on systems that preserve case in filenames.
> 
> and this source code comment:
> 
> >   /* Always lower-case drive letters a-z, even if the filesystem
> >      preserves case in filenames.
> >      This is so filenames can be compared by string comparison
> >      functions that are case-sensitive.  Even case-preserving filesystems
> >      do not distinguish case in drive letters.  */
> 
> If the return value of file-truename is used in comparisons, then
> perhaps the best answer would be unconditionally downcasing the drive
> letter (in the windows-specific part of the code) even if
> w32-long-file-name returns nil.
> 
> OTOH, I'm not sure what's the canonical truename of a non-existent
> file. Doc about file-truename (in the Elisp reference) seems to assume
> the arg is the name of an existing file, but the function takes pains
> to returns a non-nil value even if the file does not exist...

Jason sent me the full user report, which said:

> (file-truename "C:/temp/a_file")
> returns "C:/temp/a_file" if the file does not exist
> and "c:/temp/a_file" if it does.
> 
> This causes confusion if you do a find-file on C:/temp/a_file
> edit it and save it. Then do a find-file on c:/temp/a_file.
> You will get two different edits on the same file.

which I followed with:

> The problem is that currently there's no interface between the lisp
> level and the C functions that manipulate filenames, other than
> w32-short-file-name and w32-long-file-name, and both of these return
> nil if the file does not exist.
> 
> So to be able to call normalize_filename on a non-existent filename,
> either normalize_filename is "upgraded" to be directly accesible from
> lisp, or it is made accesible through w32-{long|short}-file-name,
> perhaps by adding an additional parameter to those functions that, if
> set to t, would make them return their normalized argument if it does
> not exists as a file. That'd be backward-compatible. To support this
> idea, I don't understand why w32-long-file-name, which is somewhat
> similar in spirit to file-truename, does return nil for unexistent
> files while the later does return a "truename" even if non-existent!
> 
> Barring that, the only other answer I can think of is making an ugly
> hack in the nt-specific code of file-truename to unconditionally downcase
> the drive letter.
> 
> All in all, I think there's a lack of definition wrt which is the
> right behavior for w32 filenames. It is worse the reported "bug" that
> this one (assuming a_file exists and a_file2 doesn not)?
> 
> ELISP> (file-truename "/temp/a_file")
> "c:/temp/a_file"
> ELISP> (file-truename "/temp/a_file2")
> "/temp/a_file2"

and then

> A posible answer, now that I've found untranslated-canonical-name does
> exactly what we needed...
> 
> Index: files.el
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/files.el,v
> retrieving revision 1.538
> diff -u -r1.538 files.el
> --- files.el	2001/11/21 12:00:32	1.538
> +++ files.el	2001/11/21 16:11:49
> @@ -618,7 +618,7 @@
>  	      (setq newname filename)
>  	    ;; If filename doesn't exist, newname will be nil.
>  	    (setq newname (w32-long-file-name filename)))
> -	  (setq filename (or newname filename)))
> +	  (setq filename (or newname (untranslated-canonical-name filename))))
>  	(setq done t)))
>  
>      ;; If this file directly leads to a link, process that iteratively

and, finally:

> > A posible answer, now that I've found untranslated-canonical-name does
> > exactly what we needed...
> 
> Except that untranslated-canonical-name calls expand-file-name, which
> produces:
> 
> > ELISP> (file-truename "~")
> > "c:/usr/home"
> > ELISP> 
> 
> Oops.
> 
> Although I'm still puzzled about *what* is the supposed behavior of
> file-truename wrt non-existent files...


                                                           /L/e/k/t/u

Re: Bug Emacs 21.3: write-file downcasing

[Eli Zaretskii]

> Date: Fri, 07 Feb 2003 16:50:11 +0100
> From: Juanma Barranquero <lektu@terra.es>
> > 
> > > 2001-11-08  Andrew.Maguire@Smallworld.co.uk (Andrew Maguire)  gnu.emacs.bug
> > >   (file-truename "C:/temp/a_file")
> > >   returns "C:/temp/a_file" if the file does not exist and
> > >   "c:/temp/a_file" if it does.
> > 
> > I'm not convinced this is a bug :)
> > 
> > If the file does not exist, the argument is returned unmodified.
> > 
> > OTOH, if the file does exist, eventually normalize_filename (in w32.c)
> > gets called, which returns the path and name exactly as it exists in
> > the filesystem, but purposefully downcases the drive letter, according
> > to this changelog entry:
> > 
> > > 1996-07-03  Andrew Innes  <andrewi@harlequin.co.uk>
> > > 
> > >         * nt.c (normalize_filename): Always lower-case drive letters, even
> > >         on systems that preserve case in filenames.
> > 
> > and this source code comment:
> > 
> > >   /* Always lower-case drive letters a-z, even if the filesystem
> > >      preserves case in filenames.
> > >      This is so filenames can be compared by string comparison
> > >      functions that are case-sensitive.  Even case-preserving filesystems
> > >      do not distinguish case in drive letters.  */
> > 
> > If the return value of file-truename is used in comparisons, then
> > perhaps the best answer would be unconditionally downcasing the drive
> > letter (in the windows-specific part of the code) even if
> > w32-long-file-name returns nil.

If the problem was that the drive letter was not downcased, I don't
see how did we arrive at downcasing the entire file name.  I don't
think the OP of this thread would oppose to having just the drive
letter be returned in lower case.

What am I missing?

Re: Bug Emacs 21.3: write-file downcasing

[Juanma Barranquero]

On Fri, 07 Feb 2003 19:16:58 +0200, "Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> What am I missing?

Nothing, except that we aren't downcasing the filename, we are
normalizing it :)

What I mean is that:

(with-current-buffer (get-buffer-create "*temp*")
  (let ((name (file-truename "/file1")))
    (insert "data\n")
    (write-file name)
    (string= name (file-truename (buffer-file-name)))))

 => nil

which is weird and potentially a bug: the truename of a file is
different before it exists and afterwards. If you save it before writing
the file, you cannot trust it.

OTOH, I think my e-mail exchange with Jason makes very explicit that I
*don't* know what's the "intuitive, most logical" behaviour in these
corner cases...

                                                           /L/e/k/t/u

Re: Bug Emacs 21.3: write-file downcasing

[Stefan Monnier]

> > What am I missing?
> 
> Nothing, except that we aren't downcasing the filename, we are
> normalizing it :)
> 
> What I mean is that:
> 
> (with-current-buffer (get-buffer-create "*temp*")
>   (let ((name (file-truename "/file1")))
>     (insert "data\n")
>     (write-file name)
>     (string= name (file-truename (buffer-file-name)))))
> 
>  => nil

IMHO the problem is that we should not use `string='.
We should have a `file-name-equal' predicate instead.
I'm not sure what its precise semantics should be, but a first step
could be something like

   (defun file-name-equal (f1 f2)
     (eq t (compare-string f1 0 nil f2 0 nil
                          (memq system-name '(windows-nt ms-dos)))))


-- Stefan

Re: Bug Emacs 21.3: write-file downcasing

[Eli Zaretskii]

> Date: Fri, 07 Feb 2003 18:33:55 +0100
> From: Juanma Barranquero <lektu@terra.es>
> 
> > What am I missing?
> 
> Nothing, except that we aren't downcasing the filename, we are
> normalizing it :)

I still don't see how a problem of downcasing the drive letter got to
normalizing the file name by downcasing all of it.

Re: Bug Emacs 21.3: write-file downcasing

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs/pretest@rum.cs.yale.edu>
> Date: Fri, 07 Feb 2003 12:57:34 -0500
> 
> IMHO the problem is that we should not use `string='.
> We should have a `file-name-equal' predicate instead.

Yes, I agree.

And then we should go through all the Lisp packages that compare file
names and make them use file-name-equal instead of string=.

Re: Bug Emacs 21.3: write-file downcasing

[Jason Rumney]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> If the problem was that the drive letter was not downcased, I don't
> see how did we arrive at downcasing the entire file name.

I believe the problem was more general, but I no longer have the bug
report that indicates this. If a user calls find-file on a
non-existent file with an upper case character anywhere in the
filename, then saves the buffer and uses compile-mode etc to jump to
some position within the buffer, previous to that change Emacs would
create a new buffer rather than using the existing one.

The report that Juanma sent dates back to Nov 2001. The change was
not installed then because the fix seemed too brute force for the
problem described. It was not until a year later when the above
behavior was reported that I installed the change.

Re: Bug Emacs 21.3: write-file downcasing

[Juanma Barranquero]

On Fri, 07 Feb 2003 20:18:12 +0200 "Eli Zaretskii" <eliz@is.elta.co.il>
wrote:

> I still don't see how a problem of downcasing the drive letter got to
> normalizing the file name by downcasing all of it.

There are two problems:

 1.- from "C:/file1" to "c:/file1"
 2.- from "/file1" to "c:/file1"

While trying to solve both, I proposed using an already existing
function: `untranslated-canonical-name'. That function does the
downcasing: (untranslated-canonical-name "/fILe1") => "c:/file1", but
that was, from the point of view of the bug fix, a side effect.

Anyway, we've had, AFAIK, just one report for the bug, and that was from
someone using 20.7; while the downcasing is obviously much more
troublesome. So reverting to the old behavior and fixing the bug in a
much less "brute force" way is IMO the best answer. :)

-- 
Juanma Barranquero <lektu@terra.es>

Re: Bug Emacs 21.3: write-file downcasing

[Eli Zaretskii]

> Date: Fri, 07 Feb 2003 21:19:25 +0100
> From: Juanma Barranquero <lektu@terra.es>
> 
> There are two problems:
> 
>  1.- from "C:/file1" to "c:/file1"
>  2.- from "/file1" to "c:/file1"
> 
> While trying to solve both, I proposed using an already existing
> function: `untranslated-canonical-name'. That function does the
> downcasing: (untranslated-canonical-name "/fILe1") => "c:/file1", but
> that was, from the point of view of the bug fix, a side effect.

If that's the side effect of using untranslated-canonical-name, then I
think we should not use it to solve this problem.

> Anyway, we've had, AFAIK, just one report for the bug, and that was from
> someone using 20.7; while the downcasing is obviously much more
> troublesome. So reverting to the old behavior and fixing the bug in a
> much less "brute force" way is IMO the best answer. :)

Right, I agree.

Re: Bug Emacs 21.3: write-file downcasing

[Richard Stallman]

    > We should have a `file-name-equal' predicate instead.

I don't like the idea of distorting Emacs that much for the sake of
Windows.

Re: Bug Emacs 21.3: write-file downcasing

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 09 Feb 2003 07:39:43 -0500
> 
>     > We should have a `file-name-equal' predicate instead.
> 
> I don't like the idea of distorting Emacs that much for the sake of
> Windows.

We already have similar solutions in place: convert-standard-filename
is a case in point.  The idea is to make any ugliness of non-Posix
systems be confined to a single place rather than spread over Lisp
packages.

In addition, I'm not sure such a primitive will be useless for Posix
platforms.  It could, for example, be useful for comparing decoded
file names with encoded ones.

In any case, the questions is what is the alternative to solve this
particular problem.  I don't think we should leave it unsolved.

Re: Bug Emacs 21.3: write-file downcasing

[Dhruva Krishnamurthy]

On Sun, 09 Feb 2003 17:52:52 +0200, "Eli Zaretskii" <eliz@is.elta.co.il>
said:
> > From: Richard Stallman <rms@gnu.org>
> > Date: Sun, 09 Feb 2003 07:39:43 -0500
> > 
> >     > We should have a `file-name-equal' predicate instead.
> > 
> > I don't like the idea of distorting Emacs that much for the sake of
> > Windows.
> 
> In any case, the questions is what is the alternative to solve this
> particular problem.  I don't think we should leave it unsolved.
> 
Just a thought:
 If this problem is left unsolved, If I try to write in to an NFS mounted
 file system, just imagine if the downcasing happens. I will end up
 having filenames which do not adhere to what I typed (as Unix file
 system is case sensitive).
This is the case in the development environment I am in. Cross-platform
development.

with regards,
dhruva
-- 
Dhruva Krishnamurthy
Home: http://www32.brinkster.com/schemer/

Re: Bug Emacs 21.3: write-file downcasing

[Eli Zaretskii]

On Mon, 10 Feb 2003, Dhruva Krishnamurthy wrote:

>  If this problem is left unsolved, If I try to write in to an NFS mounted
>  file system, just imagine if the downcasing happens. I will end up
>  having filenames which do not adhere to what I typed (as Unix file
>  system is case sensitive).

Could you please try that and see if the Windows port of Emacs indeed 
downcases file names in that case?  I think it queries the system about 
the letter-case type of the underlying filesystem and behaves 
accordingly, but perhaps the primitives which do that are not called in 
the case in point.

Re: Bug Emacs 21.3: write-file downcasing

[Jason Rumney]

"Dhruva Krishnamurthy" <seagull@fastmail.fm> writes:

> Just a thought:
>  If this problem is left unsolved, If I try to write in to an NFS mounted
>  file system, just imagine if the downcasing happens.

That is not the problem we are talking about leaving unsolved. The
consensus (I think) is to back out the change that causes that and
live with the previous problem, which occurs under a much more
specific set of circumstances.

Re: Bug Emacs 21.3: write-file downcasing

[Dhruva Krishnamurthy]

On Mon, 10 Feb 2003 07:46:11 +0200 (IST), "Eli Zaretskii"
<eliz@is.elta.co.il> said:
> 
> On Mon, 10 Feb 2003, Dhruva Krishnamurthy wrote:
> 
> >  If this problem is left unsolved, If I try to write in to an NFS mounted
> >  file system, just imagine if the downcasing happens. I will end up
> >  having filenames which do not adhere to what I typed (as Unix file
> >  system is case sensitive).
> 
> Could you please try that and see if the Windows port of Emacs indeed 
> downcases file names in that case?  I think it queries the system about 
> the letter-case type of the underlying filesystem and behaves 
> accordingly, but perhaps the primitives which do that are not called in 
> the case in point.
> 

I just tried it on an NFS folder. The same downcasing happens.

with regards,
dhruva
-- 
Dhruva Krishnamurthy
Home: http://www32.brinkster.com/schemer/

Re: Bug Emacs 21.3: write-file downcasing

[Juanma Barranquero]

On 10 Feb 2003 08:21:25 +0000, Jason Rumney <jasonr@gnu.org> wrote:

> The consensus (I think) is to back out the change that causes that and
> live with the previous problem, which occurs under a much more
> specific set of circumstances.

Yes.

Moreover, filename handling in Windows should be reworked anyway. Is no
longer true that Windows doesn't support hard links and symlinks, and
currently `w32-get-long-file-name' knows nothing about it.


                                                           /L/e/k/t/u

Re: Bug Emacs 21.3: write-file downcasing

[Richard Stallman]

	>> We should have a `file-name-equal' predicate instead.
    > 
    > I don't like the idea of distorting Emacs that much for the sake of
    > Windows.

    It isn't Windows-specific: Emacs needs it handle any
    case-preserving-but-indifferent file system correctly.

Are there any other such systems we are trying to support?
I don't think so.

I am firmly against complicating Emacs for the sake of theoretical
generality.

Re: Bug Emacs 21.3: write-file downcasing

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|> 	>> We should have a `file-name-equal' predicate instead.
|>     > 
|>     > I don't like the idea of distorting Emacs that much for the sake of
|>     > Windows.
|> 
|>     It isn't Windows-specific: Emacs needs it handle any
|>     case-preserving-but-indifferent file system correctly.
|> 
|> Are there any other such systems we are trying to support?
|> I don't think so.

HFS on MacOS X, for example.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bug Emacs 21.3: write-file downcasing

[Benjamin Riefenstahl]

Hi all,


Somebody wrote:
>     It isn't Windows-specific: Emacs needs it handle any
>     case-preserving-but-indifferent file system correctly.

Richard Stallman <rms@gnu.org> writes:
> Are there any other such systems we are trying to support?  I don't
> think so.

As I see it, it's not a question of OS but of supported file systems
these days.  MacOSX is almost exclusivly installed on HFS+ today.
Many GNU/Linuxers maintain data on FAT volumes.  Others mount SMB
volumes from networked Microsoft NT servers.  All of these are
case-insensitive, like it or not.


so long, benny

PS: The real complication is non-ASCII characters in filenames.  From
my experience this is still a black art on GNU/Linux.  This is of
course one of the problems Unix (and POSIX?) tried to avoid with using
case-sensitive file systems in the first place.  But that is a
separate problem (an extension of the problem, so to speak).

Re: Bug Emacs 21.3: write-file downcasing

[Richard Stallman]

    |> Are there any other such systems we are trying to support?
    |> I don't think so.

    HFS on MacOS X, for example.

That adds to the weight of the need.  Still, I would much rather
we could avoid the need to compare file names using anything other
than string=.

Re: Bug Emacs 21.3: write-file downcasing

[Jason Rumney]

Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de> writes:

> As I see it, it's not a question of OS but of supported file systems
> these days.

I am not aware of any standard way to find out whether a file-system
is case-sensitive or not, and the standard Linux kernel drivers for
FAT and SMB based filesystems are case-sensitive even though the
underlying filesystem is case-insensitive (although patches are
available to make the drivers case insensitive where applications do
not prevent it).  So yes, unfortunately it is a question of OS these
days.

Re: Bug Emacs 21.3: write-file downcasing

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> That adds to the weight of the need.  Still, I would much rather
> we could avoid the need to compare file names using anything other
> than string=.

Even on GNU and similar systems, it is probably better to compare
inodes than strings to determine if two files are the same file.
That would deal with case-insensitive filesystems where they exist on
those platforms.

There are already places in the Emacs code where inodes are used (to
deal with hard-links), making a function available for lisp to do
such a comparison and encouraging people to use it rather than string=
seems like a good thing to me.

Re: Bug Emacs 21.3: write-file downcasing

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > That adds to the weight of the need.  Still, I would much rather
> > we could avoid the need to compare file names using anything other
> > than string=.
> 
> Even on GNU and similar systems, it is probably better to compare
> inodes than strings to determine if two files are the same file.
> That would deal with case-insensitive filesystems where they exist on
> those platforms.
> 
> There are already places in the Emacs code where inodes are used (to
> deal with hard-links), making a function available for lisp to do
> such a comparison and encouraging people to use it rather than string=
> seems like a good thing to me.

So there are really two issues here when comparing two file names A and B:

1) do A and B name the same file  (could be in different directories)
 
2) are A and B the "same" file name, if underlaying FS is case insensitive.

In case 1), comparing inodes (when available) will be the correct solution.

In case 2), just comparing inodes doesn't help.


Furthermore, if the file hasn't been created yet, you cannot use inodes to
compare names A and B...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug Emacs 21.3: write-file downcasing

[Benjamin Riefenstahl]

Hi Jason,


> Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de> writes:
> > As I see it, it's not a question of OS but of supported file
> > systems these days.

Jason Rumney <jasonr@gnu.org> writes:
> I am not aware of any standard way to find out whether a file-system
> is case-sensitive or not,

I thought so and that is a problem.  I was of course talking about the
user view.

> and the standard Linux kernel drivers for FAT and SMB based
> filesystems are case-sensitive even though the underlying filesystem
> is case-insensitive (although patches are available to make the
> drivers case insensitive where applications do not prevent it).

Depends on what you mean by case-sensitive.  I tested this yesterday
before posting.  My test was:

  $ echo 1 > test
  $ echo 2 >> Test
  $ cat test
  1
  2
  $

That was the result on my Linux/PPC (2.4.0) system both for a mounted
FAT floppy image and an NT volume.  Those systems do not even support
case-sensitive operation in a strict sense of the word (NT servers
could in theory support it, but it practice they don't).

> So yes, unfortunately it is a question of OS these days.

We could conclude that the problem is not easily solved on GNU/Linux,
or that it can only be solved with a user setting, but the situation
on MacOSX is still pretty clear.


so long, benny

Re: Bug Emacs 21.3: write-file downcasing

[Andreas Schwab]

Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de> writes:

|> We could conclude that the problem is not easily solved on GNU/Linux,
|> or that it can only be solved with a user setting, but the situation
|> on MacOSX is still pretty clear.

Is it?  MacOSX also has UFS, and NFS is case-sensitive as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bug Emacs 21.3: write-file downcasing

[Benjamin Riefenstahl]

Hi Andreas,


Andreas Schwab <schwab@suse.de> writes:

> Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de> writes:
> |> We could conclude that the problem is not easily solved on
> |> GNU/Linux, or that it can only be solved with a user setting, but
> |> the situation on MacOSX is still pretty clear.
> 
> Is it?  MacOSX also has UFS, and NFS is case-sensitive as well.

But Apple discourages UFS.  They don't even guarantee that all MacOSX
components work on UFS so it is pretty unlikely.  NFS is
case-sensitive for Windows clients as well, so that's not the point.
Or rather it was my point some messages back for a slightly different
question ;-).

If I see this right, the common user on MacOSX works on HFS+,
AppleTalk (plain Mac shops) or SMB volumes (corporate users), all
case-insensitive.  The common user on GNU/Linux works on ext2, ext3,
NFS (case-sensitive), some have secondary volumes on FAT and SMB
(case-insensitive).  Seeing your affiliation you probably have better
data on GNU/Linux users ;-).


so long, benny

Re: Bug Emacs 21.3: write-file downcasing

[Kevin Rodgers]

Jason Rumney wrote:

> There are already places in the Emacs code where inodes are used (to
> deal with hard-links), making a function available for lisp to do
> such a comparison and encouraging people to use it rather than string=
> seems like a good thing to me.

Actually, I've run into a problem that I think is a result of Emacs assuming
each distinct file has a unique inode: On Network Appliance NFS servers, there
is a snapshot mechanism that is used to retain old versions of files at
configurable intervals.  Those files are stored in read-only subdirectories,
via pointers to the original disk blocks, and apparently they share inodes.
Here's a real example of some `ls -lrti` output:

   23541505 -rw-rw-r--   1 edoc     edoc        1157 Feb  4 06:00 
.snapshot/nightly.7/PipeStatus.rpt
   23541505 -rw-rw-r--   1 edoc     edoc        1097 Feb  5 06:00 
.snapshot/nightly.6/PipeStatus.rpt
   23541505 -rw-rw-r--   1 edoc     edoc        1127 Feb  6 06:00 
.snapshot/nightly.5/PipeStatus.rpt
   23541505 -rw-rw-r--   1 edoc     edoc        1187 Feb  7 06:00 
.snapshot/nightly.4/PipeStatus.rpt
   23541505 -rw-rw-r--   1 edoc     edoc        1187 Feb  7 06:00 
.snapshot/nightly.3/PipeStatus.rpt
   23541505 -rw-rw-r--   1 edoc     edoc        1187 Feb  7 06:00 
.snapshot/nightly.2/PipeStatus.rpt
   23541505 -rw-rw-r--   1 edoc     edoc        1187 Feb 10 06:00 
.snapshot/nightly.1/PipeStatus.rpt
   23541505 -rw-rw-r--   1 edoc     edoc        1187 Feb 11 06:00 
.snapshot/nightly.0/PipeStatus.rpt
   23541505 -rw-rw-r--   1 edoc     edoc        1187 Feb 11 06:00 
.snapshot/hourly.0/PipeStatus.rpt
   23541505 -rw-rw-r--   1 edoc     edoc        1217 Feb 12 06:00 PipeStatus.rpt

Even though these files have different contents, sizes, and timestamps, they
share the same inode number.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Bug Emacs 21.3: write-file downcasing

[Jason Rumney]

storm@cua.dk (Kim F. Storm) writes:

> So there are really two issues here when comparing two file names A and B:
> 
> 1) do A and B name the same file  (could be in different directories)
>  
> 2) are A and B the "same" file name, if underlaying FS is case insensitive.
> 
> In case 1), comparing inodes (when available) will be the correct solution.
> 
> In case 2), just comparing inodes doesn't help.

No, but comparing inodes and file-names in a case-insensitive way
does solve 2).

> Furthermore, if the file hasn't been created yet, you cannot use inodes to
> compare names A and B...

Correct, and that is the case that currently fails under MS-Windows.
So I don't think we have made any progress. I am currently swinging
back to RMS's viewpoint that introducing this new function is not
needed, since I am not aware of any bugs that introducing it would
fix.

Re: Bug Emacs 21.3: write-file downcasing

[Jason Rumney]

Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de> writes:

> Depends on what you mean by case-sensitive.  I tested this yesterday
> before posting.  My test was:
> 
>   $ echo 1 > test
>   $ echo 2 >> Test
>   $ cat test
>   1
>   2
>   $

Try using wild-cards, or completion and you will see. But I guess
that is bash, rather than the file system itself.

> We could conclude that the problem is not easily solved on GNU/Linux,
> or that it can only be solved with a user setting, but the situation
> on MacOSX is still pretty clear.

If there is a problem on GNU/Linux, and I'm not convinced that there
is, it could easily be solved by a test that combined both inode and
file-name information. The same edge cases that we have with new files
on MS-Windows and with dodgy NFS servers still apply though, and these
are difficult to solve.

Re: Bug Emacs 21.3: write-file downcasing

[Andreas Schwab]

Kevin Rodgers <kevin.rodgers@ihs.com> writes:

|> Even though these files have different contents, sizes, and timestamps, they
|> share the same inode number.

Do they also share the same device number?  Otherwise that looks pretty
much broken, many other utilities probably fail to work properly with such
files.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bug Emacs 21.3: write-file downcasing

[Kevin Rodgers]

Andreas Schwab wrote:

> Kevin Rodgers <kevin.rodgers@ihs.com> writes:
> 
> |> Even though these files have different contents, sizes, and timestamps, they
> |> share the same inode number.
> 
> Do they also share the same device number?  Otherwise that looks pretty
> much broken, many other utilities probably fail to work properly with such
> files.


Yes they do share the same device number, and I have seen at least one
utility fail -- I think it was diff on OSF1/Digital Unix, which assumed
that files with the same inode were identical.

I'll try to get some info from Network Appliance.  In the meantime, you
might be interested in this:

http://www.netapp.com/tech_library/3002.html#I4

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>