[gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Chong Yidong]

[-- Attachment #1: Type: text/plain, Size: 73 bytes --]

Does anyone here have a vfat/ntfs partition for investigating this bug?


[-- Attachment #2: Type: message/rfc822, Size: 10058 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 3212 bytes --]


Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing
list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

The problem I have occurrs every time I start emacs so that my current
directory is either on a vfat fileystem or ntfs filesystem. Emacs
starts,
but it complains about errors when opening output file while processing
my .emacs file and the other files it tries to load.

I do not have emacs runing in a debugger, but I started it with
--debug-init
as instructed, and the resulting output is attached to this e-mail.

Best regards,

Petri Kaurinkoski


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/22.1/etc/DEBUG for instructions.


In GNU Emacs 22.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2007-12-15 on noname, modified by Debian
Windowing system distributor `The X.Org Foundation', version
11.0.10300000
configured using `configure  '--build=i486-linux-gnu'
'--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs22:/etc/emacs:/usr/local/share/emacs/22.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.1/leim' '--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: HTML

Minor modes in effect:
  show-paren-mode: t
  encoded-kbd-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> 
<report-emacs-bug>

Recent messages:
File error: Opening output file, invalid
argument, /mnt/scratch/Uinti/hss/doc/www/raw_html/hss/fin/petrin/uinti/#*scratch*#20913s5z#

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the `--debug-init' option to view a complete error backtrace.

Loading sgml-mode...done
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done

-- 
 Petri Kaurinkoski <Petri.Kaurinkoski@iki.fi>

[-- Attachment #2.1.2: emacs-backtrace.dump --]
[-- Type: application/octet-stream, Size: 2559 bytes --]

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 23 Feb 2008 17:00:52 -0500
> 
> Does anyone here have a vfat/ntfs partition for investigating this bug?

There's no need to investigate, as the problem is clearly evident:
Windows-based filesystems don't allow certain characters in file
names, and `*' is one of these characters.  So a file name such as
`#*scratch*#20913s5z#' is not allowed.

To properly fix such a problem, Emacs needs to know the type of
filesystem of a file.  Then we could employ the same technique as the
Windows port does now, but conditioned by the filesystem, not the OS.

However, I don't think we have infrastructure for querying the file
about its filesystem type, do we?

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> There's no need to investigate, as the problem is clearly evident:
> Windows-based filesystems don't allow certain characters in file
> names, and `*' is one of these characters.  So a file name such as
> `#*scratch*#20913s5z#' is not allowed.
>
> To properly fix such a problem, Emacs needs to know the type of
> filesystem of a file.  Then we could employ the same technique as the
> Windows port does now, but conditioned by the filesystem, not the OS.
>
> However, I don't think we have infrastructure for querying the file
> about its filesystem type, do we?

If our initial attempt fails, we could silently try falling back to a
different format that is appropriate for Windows-based filesystems.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chong Yidong <cyd@stupidchicken.com>
>> Date: Sat, 23 Feb 2008 17:00:52 -0500
>> 
>> Does anyone here have a vfat/ntfs partition for investigating this bug?
>
> There's no need to investigate, as the problem is clearly evident:
> Windows-based filesystems don't allow certain characters in file
> names, and `*' is one of these characters.  So a file name such as
> `#*scratch*#20913s5z#' is not allowed.
>
> To properly fix such a problem, Emacs needs to know the type of
> filesystem of a file.  Then we could employ the same technique as the
> Windows port does now, but conditioned by the filesystem, not the OS.
>
> However, I don't think we have infrastructure for querying the file
> about its filesystem type, do we?

A similar problem would be filename completion.  We have separate code
paths for that in Windows/Unix I believe, even though on MacOSX, the
file system tends to be case insensitive, too (and normalizing utf-8
composed characters in some manner).

If we could design some sort of system call sequence that worked out
insensitivity/normalizing agnostic, this would mean that on a typical
GNU/Linux system which can mount various foreign file system types,
everything would work out according to expectations.

That would seem to be preferable to #ifdef and its ilk.  I think,
however, that stuff like the "\\" directory separator can be system
rather than file system dependent.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Chong Yidong <cyd@stupidchicken.com>,  emacs-devel@gnu.org
> Date: Sat, 23 Feb 2008 23:33:08 +0100
> 
> A similar problem would be filename completion.  We have separate code
> paths for that in Windows/Unix I believe, even though on MacOSX, the
> file system tends to be case insensitive, too (and normalizing utf-8
> composed characters in some manner).
> 
> If we could design some sort of system call sequence that worked out
> insensitivity/normalizing agnostic, this would mean that on a typical
> GNU/Linux system which can mount various foreign file system types,
> everything would work out according to expectations.
> 
> That would seem to be preferable to #ifdef and its ilk.  I think,
> however, that stuff like the "\\" directory separator can be system
> rather than file system dependent.

I believe you are talking about expand-file-name, because
file_name_completion is almost devoid of OS-dependent #ifdef's.

As for expand-file-name, the #ifdef's there are mostly due to the
different semantics of file names: backslashes and drive letters, and
also to the fact that ~user is not supported.  Most of these will have
to stay OS-dependent, I think.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Jason Rumney]

Eli Zaretskii wrote:
>> From: Chong Yidong <cyd@stupidchicken.com>
>> Date: Sat, 23 Feb 2008 17:00:52 -0500
>>
>> Does anyone here have a vfat/ntfs partition for investigating this bug?
>>     
>
> There's no need to investigate, as the problem is clearly evident:
> Windows-based filesystems don't allow certain characters in file
> names, and `*' is one of these characters.  So a file name such as
> `#*scratch*#20913s5z#' is not allowed.
>
> To properly fix such a problem, Emacs needs to know the type of
> filesystem of a file.  Then we could employ the same technique as the
> Windows port does now, but conditioned by the filesystem, not the OS.
>
> However, I don't think we have infrastructure for querying the file
> about its filesystem type, do we?
>   

Alternatively, we could limit the filenames we generate for autosaving 
the scratch buffer (and any others like it) to use characters that are 
valid on all the filesystems we know about.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Stefan Monnier]

>>> Does anyone here have a vfat/ntfs partition for investigating this bug?
>> 
>> There's no need to investigate, as the problem is clearly evident:
>> Windows-based filesystems don't allow certain characters in file
>> names, and `*' is one of these characters.  So a file name such as
>> `#*scratch*#20913s5z#' is not allowed.
>> 
>> To properly fix such a problem, Emacs needs to know the type of
>> filesystem of a file.  Then we could employ the same technique as the
>> Windows port does now, but conditioned by the filesystem, not the OS.
>> 
>> However, I don't think we have infrastructure for querying the file
>> about its filesystem type, do we?

> Alternatively, we could limit the filenames we generate for autosaving the
> scratch buffer (and any others like it) to use characters that are valid on
> all the filesystems we know about.

That's indeed what we should do.  If and when we ever get support for
filesystem-knowledge in the code, we may revisit this choice, but for
now, please someone change the code that auto-generates those filenames
to avoid characters known to be problematic.  Or better yet: to only
use those chars expected to be always work.


        Stefan

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Miles Bader]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> That's indeed what we should do.  If and when we ever get support for
> filesystem-knowledge in the code, we may revisit this choice, but for
> now, please someone change the code that auto-generates those filenames
> to avoid characters known to be problematic.  Or better yet: to only
> use those chars expected to be always work.

Isn't that sort of dangerous?  If Emacs only uses characters which are
_garanteed_ to work on any no matter how stupid, that would seem to
dramatically increase the chances of a clash with a real filename...

-Miles

-- 
Cat, n. A soft, indestructible automaton provided by nature to be kicked when
things go wrong in the domestic circle.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Jason Rumney]

Miles Bader wrote:
> Isn't that sort of dangerous?  If Emacs only uses characters which are
> _garanteed_ to work on any no matter how stupid, that would seem to
> dramatically increase the chances of a clash with a real filename...
>   
autosave files and backup files already have that possibility, but noone 
has worried about it in the past.
By avoiding *?<>|" and control characters, we slightly reduce the 
possibilities for file names, but I don't think the chance of a clash 
realistically increases that much, as long as we use some unusual 
characters like # and/or ~ and append the process id or whatever the 
number is we're appending.

Even on filesystems that support them, those characters can be 
problematic for naive users who forget to quote them, so avoiding them 
is a good idea in general.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Eli Zaretskii]

> Date: Sun, 24 Feb 2008 16:01:31 +0000
> From: Jason Rumney <jasonr@gnu.org>
> CC: Stefan Monnier <monnier@IRO.UMontreal.CA>, 
>  Eli Zaretskii <eliz@gnu.org>,
>  Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
> 
> By avoiding *?<>|" and control characters

Don't forget the colon `:'.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Stefan Monnier]

>> That's indeed what we should do.  If and when we ever get support for
>> filesystem-knowledge in the code, we may revisit this choice, but for
>> now, please someone change the code that auto-generates those filenames
>> to avoid characters known to be problematic.  Or better yet: to only
>> use those chars expected to be always work.

> Isn't that sort of dangerous?  If Emacs only uses characters which are
> _garanteed_ to work on any no matter how stupid, that would seem to
> dramatically increase the chances of a clash with a real filename...

A good reason to save those non-file-buffers in a separate directory.


        Stefan

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Richard Stallman]

    > Isn't that sort of dangerous?  If Emacs only uses characters which are
    > _garanteed_ to work on any no matter how stupid, that would seem to
    > dramatically increase the chances of a clash with a real filename...

    A good reason to save those non-file-buffers in a separate directory.

There are disadvantages to that.

If that separate directory is under the user's home dir, other people
who can edit the same file will have trouble finding it.

It could be under the same directory as the file being edited,
but that involves creating a directory for this under each directory
where you edit files.

It is a good option to offer, but I don't think it should be the default.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Stefan Monnier]

>> Isn't that sort of dangerous?  If Emacs only uses characters which are
>> _garanteed_ to work on any no matter how stupid, that would seem to
>> dramatically increase the chances of a clash with a real filename...

>     A good reason to save those non-file-buffers in a separate directory.

> There are disadvantages to that.

> If that separate directory is under the user's home dir, other people
> who can edit the same file will have trouble finding it.

> It could be under the same directory as the file being edited,
> but that involves creating a directory for this under each directory
> where you edit files.

What "file being edited"?  I'm talking about "non-file-buffers".


        Stefan

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Richard Stallman]

    What "file being edited"?  I'm talking about "non-file-buffers".

Sorry, I overlooked those words.

For non-file buffers, I agree it seems ok.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>, Chong Yidong <cyd@stupidchicken.com>,
>         emacs-devel@gnu.org
> Date: Sun, 24 Feb 2008 10:39:23 -0500
> 
> > Alternatively, we could limit the filenames we generate for autosaving the
> > scratch buffer (and any others like it) to use characters that are valid on
> > all the filesystems we know about.
> 
> That's indeed what we should do.

I suspect that Unix users will hate us for that.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Richard Stallman]

    That's indeed what we should do.  If and when we ever get support for
    filesystem-knowledge in the code, we may revisit this choice, but for
    now, please someone change the code that auto-generates those filenames
    to avoid characters known to be problematic.  Or better yet: to only
    use those chars expected to be always work.

I think that changing from # to something else is a drastic change,
and I would not want to do that now.  For instance, as Miles said,

    Isn't that sort of dangerous?  If Emacs only uses characters which are
    _garanteed_ to work on any no matter how stupid, that would seem to
    dramatically increase the chances of a clash with a real filename...

There could be other characters that in practice will be no pain.
But I think it is wiser to try that in Emacs 23.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Jason Rumney]

Richard Stallman wrote:
>     That's indeed what we should do.  If and when we ever get support for
>     filesystem-knowledge in the code, we may revisit this choice, but for
>     now, please someone change the code that auto-generates those filenames
>     to avoid characters known to be problematic.  Or better yet: to only
>     use those chars expected to be always work.
>
> I think that changing from # to something else is a drastic change,
>   

# is not the problem, at least for vfat and ntfs filesystems. The 
problem that was reported was with the *s in #*scratch*#12345xyz#.

If we limit the change to non-file buffers (which seems reasonable, 
since the default is to save the auto-save file in the same directory as 
the file, and if there are invalid characters in the name of a newly 
created buffer, the user will need to fix it before they can save 
anyway), then there is already an escape mechanism in place to deal with 
/ and \ characters. Extending that to also deal with other characters 
does not seem too drastic.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Richard Stallman]

    # is not the problem, at least for vfat and ntfs filesystems. The 
    problem that was reported was with the *s in #*scratch*#12345xyz#.

I see.  So it is a matter of changing certain chars when they appear
in buffer names.  That seems harmless; make-auto-save-file-name
already does some such transformations.  There's no harm adding more.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Jason Rumney]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Richard Stallman wrote:
>     # is not the problem, at least for vfat and ntfs filesystems. The 
>     problem that was reported was with the *s in #*scratch*#12345xyz#.
>
> I see.  So it is a matter of changing certain chars when they appear
> in buffer names.  That seems harmless; make-auto-save-file-name
> already does some such transformations.  There's no harm adding more.
>   

Here is a patch against EMACS_22_BASE. Chong, Stefan, is it OK to check 
this in now, or do you want to leave the branch until after 22.2 is 
released and only fix it in the trunk now.



[-- Attachment #2: files.el.patch --]
[-- Type: text/plain, Size: 2335 bytes --]

*** files.el.~1.896.2.38.~	2008-02-24 16:51:32.796875000 +0000
--- files.el	2008-02-25 23:54:34.618303900 +0000
***************
*** 4561,4575 ****
      (let ((buffer-name (buffer-name))
  	  (limit 0)
  	  file-name)
!       ;; Eliminate all slashes and backslashes by
!       ;; replacing them with sequences that start with %.
        ;; Quote % also, to keep distinct names distinct.
!       (while (string-match "[/\\%]" buffer-name limit)
  	(let* ((character (aref buffer-name (match-beginning 0)))
  	       (replacement
  		(cond ((eq character ?%) "%%")
  		      ((eq character ?/) "%+")
! 		      ((eq character ?\\) "%-"))))
  	  (setq buffer-name (replace-match replacement t t buffer-name))
  	  (setq limit (1+ (match-end 0)))))
        ;; Generate the file name.
--- 4561,4593 ----
      (let ((buffer-name (buffer-name))
  	  (limit 0)
  	  file-name)
!       ;; Eliminate all slashes, backslashes, wildcards and other
!       ;; characters that are not valid in VFAT/NTFS filesystems.
        ;; Quote % also, to keep distinct names distinct.
!       ;; We do this on all platforms, because even if we are not
!       ;; running on DOS/Windows, the current directory may be on a
!       ;; mounted VFAT filesystem, such as a USB memory stick.
!       (while (string-match "[/\\%?*:<>|\"\000-\037]" buffer-name limit)
  	(let* ((character (aref buffer-name (match-beginning 0)))
  	       (replacement
  		(cond ((eq character ?%) "%%")
  		      ((eq character ?/) "%+")
! 		      ((eq character ?\\) "%-")
! 		      ((eq character ??) "%!")
! 		      ((eq character ?*) "%#")
! 		      ((eq character ?\") "%'")
! 		      ((eq character ?<) "%(")
! 		      ((eq character ?>) "%)")
! 		      ((eq character ?|) "%_")
! 		      ((eq character ?:) "%;")
! 		      ;; Control characters. ^@ to ^Z match their standard
! 		      ;; mappings (ie ^A is represented as %A)
! 		      ((< character 27) (concat "%" (+ character ?@)))
! 		      ;; The last few are a bit arbitrary, since the standard
! 		      ;; notation uses invalid characters and characters we
! 		      ;; have already used above.
! 		      ((< character 32)
! 		       (concat "%" (+ (- character 27) ?0))))))
  	  (setq buffer-name (replace-match replacement t t buffer-name))
  	  (setq limit (1+ (match-end 0)))))
        ;; Generate the file name.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Stefan Monnier]

> Here is a patch against EMACS_22_BASE.

I'd rather use a less arbitrary scheme.  E.g.
- only accept unchanged safe chars (rather than rule out
  dangerous ones), e.g. [:alnum:] and maybe a couple more.
- everything else encoded following quoted-printable.

Of course, QP applies to bytes, not to chars, which also points to
a potential problem with [:alnum:] since it includes multibyte chars
which may also be rejected, but I think that would be safe enough for
a start.

> Chong, Stefan, is it OK to check this in now, or do you want to leave
> the branch until after 22.2 is released and only fix it in the
> trunk now.

I'd include it in 22.2, tho it depends on the final shape of the code.


        Stefan

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Here is a patch against EMACS_22_BASE.
>
> I'd rather use a less arbitrary scheme.  E.g.
> - only accept unchanged safe chars (rather than rule out
>   dangerous ones), e.g. [:alnum:] and maybe a couple more.
> - everything else encoded following quoted-printable.
>
> Of course, QP applies to bytes, not to chars, which also points to
> a potential problem with [:alnum:] since it includes multibyte chars
> which may also be rejected, but I think that would be safe enough for
> a start.

What do you mean by quoted-printable?

I was thinking that we could instead change all unsafe chars into the
same character, e.g. an underscore.  I don't think there is much risk
of name clashing (in the first place, we already use make-temp-file to
generate a unique filename.)

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Stefan Monnier]

>>> Here is a patch against EMACS_22_BASE.
>> 
>> I'd rather use a less arbitrary scheme.  E.g.
>> - only accept unchanged safe chars (rather than rule out
>> dangerous ones), e.g. [:alnum:] and maybe a couple more.
>> - everything else encoded following quoted-printable.
>> 
>> Of course, QP applies to bytes, not to chars, which also points to
>> a potential problem with [:alnum:] since it includes multibyte chars
>> which may also be rejected, but I think that would be safe enough for
>> a start.

> What do you mean by quoted-printable?

QP uses "=NN" where NN is the hexadecimal code of the encoded byte.
Using "%NN" instead would work as well, of course.
Or maybe "%NNNN%" so as to accept arbitrary chars rather than just bytes.

> I was thinking that we could instead change all unsafe chars into the
> same character, e.g. an underscore.  I don't think there is much risk
> of name clashing (in the first place, we already use make-temp-file to
> generate a unique filename.)

That would be simpler, indeed.  But I cannot assess the risk and the
current code goes through some extra trouble to avoid name clashes, so
it seems safer to follow the original code's intention (and implicit
risk assessment).


        Stefan

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Jason Rumney]

Chong Yidong wrote:
> What do you mean by quoted-printable?
>   

Given that we already use % as an escape character, and that = could be 
mistaken for an environment variable assignment, I think URL encoding 
might be more suitable. But the differences between the two are trivial.

> I was thinking that we could instead change all unsafe chars into the
> same character, e.g. an underscore.  I don't think there is much risk
> of name clashing (in the first place, we already use make-temp-file to
> generate a unique filename.)
>   

We already have code in place to do the escaping, so moving to a less 
comprehensive solution does not save us any effort.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Jason Rumney]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Stefan Monnier wrote:
>> Here is a patch against EMACS_22_BASE.
>>     
>
> I'd rather use a less arbitrary scheme.  E.g.
> - only accept unchanged safe chars (rather than rule out
>   dangerous ones), e.g. [:alnum:] and maybe a couple more.
> - everything else encoded following quoted-printable.
>
> Of course, QP applies to bytes, not to chars, which also points to
> a potential problem with [:alnum:] since it includes multibyte chars
> which may also be rejected, but I think that would be safe enough for
> a start.
>   

OK, here's a revised patch that accepts only ASCII alphanumerics, -, _, 
., ~, # and +, and percent encodes all others.
It's not strict URL encoding, since multibyte characters will be 
translated to more than two hex characters, but as far as I can tell the 
encoding doesn't have to be reversable, just give unique names that 
don't contain invalid characters, so I think it is good enough. On the 
trunk it is cheap and easy to convert to utf-8, so we could properly URL 
encode them there.



[-- Attachment #2: files.el.patch --]
[-- Type: text/plain, Size: 1571 bytes --]

*** files.el.~1.896.2.38.~	2008-02-24 16:51:32.796875000 +0000
--- files.el	2008-02-26 09:27:34.078125000 +0000
***************
*** 4561,4575 ****
      (let ((buffer-name (buffer-name))
  	  (limit 0)
  	  file-name)
!       ;; Eliminate all slashes and backslashes by
!       ;; replacing them with sequences that start with %.
!       ;; Quote % also, to keep distinct names distinct.
!       (while (string-match "[/\\%]" buffer-name limit)
  	(let* ((character (aref buffer-name (match-beginning 0)))
  	       (replacement
! 		(cond ((eq character ?%) "%%")
! 		      ((eq character ?/) "%+")
! 		      ((eq character ?\\) "%-"))))
  	  (setq buffer-name (replace-match replacement t t buffer-name))
  	  (setq limit (1+ (match-end 0)))))
        ;; Generate the file name.
--- 4561,4576 ----
      (let ((buffer-name (buffer-name))
  	  (limit 0)
  	  file-name)
!       ;; Restrict the characters used in the file name to those which
!       ;; are known to be safe on all filesystems, url-encoding the
!       ;; rest.
!       ;; We do this on all platforms, because even if we are not
!       ;; running on DOS/Windows, the current directory may be on a
!       ;; mounted VFAT filesystem, such as a USB memory stick.
!       (while (string-match "[^A-Za-z0-9-_.~#+]" buffer-name limit)
  	(let* ((character (aref buffer-name (match-beginning 0)))
  	       (replacement
!                 (format "%%%02X" character)))
  	  (setq buffer-name (replace-match replacement t t buffer-name))
  	  (setq limit (1+ (match-end 0)))))
        ;; Generate the file name.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Stefan Monnier]

> OK, here's a revised patch that accepts only ASCII alphanumerics, -, _, .,
> ~, # and +, and percent encodes all others.
> It's not strict URL encoding, since multibyte characters will be translated
> to more than two hex characters, but as far as I can tell the encoding
> doesn't have to be reversable, just give unique names that don't contain
> invalid characters, so I think it is good enough. On the trunk it is cheap
> and easy to convert to utf-8, so we could properly URL encode them there.



> *** files.el.~1.896.2.38.~	2008-02-24 16:51:32.796875000 +0000
> --- files.el	2008-02-26 09:27:34.078125000 +0000
> ***************
> *** 4561,4575 ****
>       (let ((buffer-name (buffer-name))
>   	  (limit 0)
>   	  file-name)
> !       ;; Eliminate all slashes and backslashes by
> !       ;; replacing them with sequences that start with %.
> !       ;; Quote % also, to keep distinct names distinct.
> !       (while (string-match "[/\\%]" buffer-name limit)
>   	(let* ((character (aref buffer-name (match-beginning 0)))
>   	       (replacement
> ! 		(cond ((eq character ?%) "%%")
> ! 		      ((eq character ?/) "%+")
> ! 		      ((eq character ?\\) "%-"))))
>   	  (setq buffer-name (replace-match replacement t t buffer-name))
>   	  (setq limit (1+ (match-end 0)))))
>         ;; Generate the file name.
> --- 4561,4576 ----
>       (let ((buffer-name (buffer-name))
>   	  (limit 0)
>   	  file-name)
> !       ;; Restrict the characters used in the file name to those which
> !       ;; are known to be safe on all filesystems, url-encoding the
> !       ;; rest.
> !       ;; We do this on all platforms, because even if we are not
> !       ;; running on DOS/Windows, the current directory may be on a
> !       ;; mounted VFAT filesystem, such as a USB memory stick.
> !       (while (string-match "[^A-Za-z0-9-_.~#+]" buffer-name limit)
>   	(let* ((character (aref buffer-name (match-beginning 0)))
>   	       (replacement
> !                 (format "%%%02X" character)))
>   	  (setq buffer-name (replace-match replacement t t buffer-name))
>   	  (setq limit (1+ (match-end 0)))))
>         ;; Generate the file name.

Looks good.  Feel free to install it on the 22 branch (assuming you've
actually tested it, of course).


        Stefan

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Richard Stallman]

    Alternatively, we could limit the filenames we generate for autosaving 
    the scratch buffer (and any others like it) to use characters that are 
    valid on all the filesystems we know about.

In principle, that isn't bad, but in practice is there a good solution
of that kind?

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Richard Stallman]

    There's no need to investigate, as the problem is clearly evident:
    Windows-based filesystems don't allow certain characters in file
    names, and `*' is one of these characters.  So a file name such as
    `#*scratch*#20913s5z#' is not allowed.

If this were just a minor problem, it would make sense to say "use a
different name".  But this is such a painful and broad problem that it
is worth fixing if possible.

One possible solution would be for Fdo_auto_save to detect that errno
code when `open' fails, and modify the file name.  Maybe it should
also set a flag which Lisp code can see.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Sun, 24 Feb 2008 10:23:03 -0500
> 
> One possible solution would be for Fdo_auto_save to detect that errno
> code when `open' fails, and modify the file name.

EINVAL is not specific enough for that, IMO.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Richard Stallman]

    > One possible solution would be for Fdo_auto_save to detect that errno
    > code when `open' fails, and modify the file name.

    EINVAL is not specific enough for that, IMO.

What else causes EINVAL from `open'?

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Mon, 25 Feb 2008 05:57:27 -0500
> 
>     > One possible solution would be for Fdo_auto_save to detect that errno
>     > code when `open' fails, and modify the file name.
> 
>     EINVAL is not specific enough for that, IMO.
> 
> What else causes EINVAL from `open'?

I have no idea, since the GNU/Linux man page for `open' doesn't
mention EINVAL at all.

Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> CC: cyd@stupidchicken.com, emacs-devel@gnu.org
>> Date: Mon, 25 Feb 2008 05:57:27 -0500
>> 
>>     > One possible solution would be for Fdo_auto_save to detect that errno
>>     > code when `open' fails, and modify the file name.
>> 
>>     EINVAL is not specific enough for that, IMO.
>> 
>> What else causes EINVAL from `open'?
>
> I have no idea, since the GNU/Linux man page for `open' doesn't
> mention EINVAL at all.

POSIX defines two cases:

- The value of the oflag argument is not valid.
- The implementation does not support synchronized I/O for this file.

The latter is only applicable when the synchronized I/O extensions are
supported and any of the O_SYNC/O_DSYNC/O_RSYNC flags is used.

An implementation can define arbitrary extra cases in addition to the
ones mentioned by POSIX.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."