Problem with non-valid file names on w32

Problem with non-valid file names on w32

[Lennart Borgman]

Emacs does not try to find out whether a file name is valid when you for 
example runs find-file. On w32 you can do things like this:

    C-x C-f c:/some/path/hello<there.txt

This will open a new buffer with buffer-file-name equal to 
"c:/some/path/hello<there.txt". This is an invalid file name on w32.

You can do similar things with emacsclient:

    C:\> emacsclient "c:/some/path/hello<there.txt"

which leads to similar results.

When you try to save the file Emacs will be noted about the problem and 
tell the user. So maybe it is not that catastrophic, but it is not 
pretty IMO.

It gets a bit worse if you have file names like 
"c:/some/path/d:hidden.txt". In this case Emacs will not complain when 
saving the file. Instead a hidden stream is created.

I think it would be good to check for the forbidden characters, probably 
then when expanding a file name. I think that many users would feel more 
comfortable if Emacs behaved that way. This seems to be the way our 
famous relative Notepad does it. (Except for the awkward hidden case.)

BTW, the characters that are invalid in w32 file names are:

   :*?\"<>|

Unfortunately I know no good way (ie a w32 API) to test if a file name 
is valid, but an easy workaround is of course to search for these 
characters.

Re: Problem with non-valid file names on w32

[Juanma Barranquero]

On 11/30/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> When you try to save the file Emacs will be noted about the problem and
> tell the user. So maybe it is not that catastrophic, but it is not
> pretty IMO.

If you have shared resources, the rules governing file name validity
could be different in some mounted volumes. How do you plan to say
that to Emacs?

> It gets a bit worse if you have file names like
> "c:/some/path/d:hidden.txt". In this case Emacs will not complain when
> saving the file. Instead a hidden stream is created.

That is a feature (if unintended). foo:bar is not an invalid name in
Windows. Moreover, it will only happen for the infamous C:foo case. If
you try C:/my/dir/d:/another/dir/file.txt the buffer will be saved
(assuming it exists) on "d:/another/dir/file.txt".

> This seems to be the way our
> famous relative Notepad does it. (Except for the awkward hidden case.)

Why do you call it "awkward"? It's a feature, and that's its syntax.
CMD does not do a very good job of handling streams, but for example
in 4NT you can do:

 C:\> copy con foo:bar
 con => foo:bar
  foobar fubar
 ^Z
      1 file copied

 C:\> type foo:bar
  foobar fubar

  C:\> dir /: foo

  Volume in drive C is unlabeled      Serial number is 0836:9fa9
  Directory of  C:\foo

 30/11/2006  14:52               0  foo
                                14    bar:$DATA
              14 bytes in 1 file and 0 dirs    0 bytes allocated
 175.102.554.112 bytes free

 C:\>

                    /L/e/k/t/u

Re: Problem with non-valid file names on w32

[Lennart Borgman]

Juanma Barranquero wrote:
> On 11/30/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> 
>> When you try to save the file Emacs will be noted about the problem and
>> tell the user. So maybe it is not that catastrophic, but it is not
>> pretty IMO.
> 
> If you have shared resources, the rules governing file name validity
> could be different in some mounted volumes. How do you plan to say
> that to Emacs?


Good point. I know little about possible mount points in w32. Can 
another volume be mounted say under c:/some/path/a/bit/down?


>> It gets a bit worse if you have file names like
>> "c:/some/path/d:hidden.txt". In this case Emacs will not complain when
>> saving the file. Instead a hidden stream is created.
...
> Why do you call it "awkward"? It's a feature, and that's its syntax.
> CMD does not do a very good job of handling streams, but for example
> in 4NT you can do:


Yes, you are right. But it is a surprising feature.

Re: Problem with non-valid file names on w32

[Stuart D. Herring]

> Good point. I know little about possible mount points in w32. Can
> another volume be mounted say under c:/some/path/a/bit/down?

I don't know the precise conditions under which it's possible, but I know
that at least sometimes, that precise cicumstance pertains.  It may only
be possible with NTFS or something like that.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Problem with non-valid file names on w32

[Mathias Dahl]

> If you have shared resources, the rules governing file name validity
> could be different in some mounted volumes. How do you plan to say
> that to Emacs?

Most probably that shared resource would add more restrictions on file
names rather than adding possible characters, right? Or is the current
file name restrictions in Windows dependent on the file system type?

> > It gets a bit worse if you have file names like
> > "c:/some/path/d:hidden.txt". In this case Emacs will not complain when
> > saving the file. Instead a hidden stream is created.
>
> That is a feature (if unintended). foo:bar is not an invalid name in
> Windows.

I agree. That might come handy.

Re: Problem with non-valid file names on w32

[Juanma Barranquero]

On 11/30/06, Mathias Dahl <mathias.dahl@gmail.com> wrote:

> Most probably that shared resource would add more restrictions on file
> names rather than adding possible characters, right?

Possibly, but it still defeats the idea of filtering the filename just
to avoid an error message to the user.

                    /L/e/k/t/u

Re: Problem with non-valid file names on w32

[Eli Zaretskii]

> Date: Thu, 30 Nov 2006 14:10:45 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> 
> Unfortunately I know no good way (ie a w32 API) to test if a file name 
> is valid

I really don't think we should fix it for w32 alone.  Emacs doesn't
check the file name for validity on _any_ system; why should Windows
behave differently?

Re: Problem with non-valid file names on w32

[Juanma Barranquero]

On 12/1/06, Eli Zaretskii <eliz@gnu.org> wrote:

> I really don't think we should fix it for w32 alone.  Emacs doesn't
> check the file name for validity on _any_ system; why should Windows
> behave differently?

I think we should *not* fix it anywhere. It's a wild goose chase,
because ultimately, it's the filesystem who knows what a valid
filename is and what is not. I don't see anything wrong with the user
getting an error message when the filename is not valid: he's won't
lose data, just retry with another name.

                    /L/e/k/t/u