* [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
@ 2008-02-23 22:00 Chong Yidong
2008-02-23 22:22 ` Eli Zaretskii
0 siblings, 1 reply; 31+ messages in thread
From: Chong Yidong @ 2008-02-23 22:00 UTC (permalink / raw)
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-23 22:00 [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem Chong Yidong
@ 2008-02-23 22:22 ` Eli Zaretskii
2008-02-23 22:30 ` Chong Yidong
` (3 more replies)
0 siblings, 4 replies; 31+ messages in thread
From: Eli Zaretskii @ 2008-02-23 22:22 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-23 22:22 ` Eli Zaretskii
@ 2008-02-23 22:30 ` Chong Yidong
2008-02-23 22:33 ` David Kastrup
` (2 subsequent siblings)
3 siblings, 0 replies; 31+ messages in thread
From: Chong Yidong @ 2008-02-23 22:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-23 22:22 ` Eli Zaretskii
2008-02-23 22:30 ` Chong Yidong
@ 2008-02-23 22:33 ` David Kastrup
2008-02-24 4:16 ` Eli Zaretskii
2008-02-24 14:36 ` Jason Rumney
2008-02-24 15:23 ` Richard Stallman
3 siblings, 1 reply; 31+ messages in thread
From: David Kastrup @ 2008-02-23 22:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Chong Yidong, emacs-devel
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-23 22:33 ` David Kastrup
@ 2008-02-24 4:16 ` Eli Zaretskii
0 siblings, 0 replies; 31+ messages in thread
From: Eli Zaretskii @ 2008-02-24 4:16 UTC (permalink / raw)
To: David Kastrup; +Cc: cyd, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-23 22:22 ` Eli Zaretskii
2008-02-23 22:30 ` Chong Yidong
2008-02-23 22:33 ` David Kastrup
@ 2008-02-24 14:36 ` Jason Rumney
2008-02-24 15:39 ` Stefan Monnier
2008-02-24 22:30 ` Richard Stallman
2008-02-24 15:23 ` Richard Stallman
3 siblings, 2 replies; 31+ messages in thread
From: Jason Rumney @ 2008-02-24 14:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Chong Yidong, emacs-devel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-23 22:22 ` Eli Zaretskii
` (2 preceding siblings ...)
2008-02-24 14:36 ` Jason Rumney
@ 2008-02-24 15:23 ` Richard Stallman
2008-02-24 20:01 ` Eli Zaretskii
3 siblings, 1 reply; 31+ messages in thread
From: Richard Stallman @ 2008-02-24 15:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, emacs-devel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 14:36 ` Jason Rumney
@ 2008-02-24 15:39 ` Stefan Monnier
2008-02-24 15:44 ` Miles Bader
` (2 more replies)
2008-02-24 22:30 ` Richard Stallman
1 sibling, 3 replies; 31+ messages in thread
From: Stefan Monnier @ 2008-02-24 15:39 UTC (permalink / raw)
To: Jason Rumney; +Cc: Eli Zaretskii, Chong Yidong, emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 15:39 ` Stefan Monnier
@ 2008-02-24 15:44 ` Miles Bader
2008-02-24 16:01 ` Jason Rumney
2008-02-24 20:41 ` Stefan Monnier
2008-02-24 19:43 ` Eli Zaretskii
2008-02-24 23:04 ` Richard Stallman
2 siblings, 2 replies; 31+ messages in thread
From: Miles Bader @ 2008-02-24 15:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel, Chong Yidong, Jason Rumney
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 15:44 ` Miles Bader
@ 2008-02-24 16:01 ` Jason Rumney
2008-02-24 19:44 ` Eli Zaretskii
2008-02-24 20:41 ` Stefan Monnier
1 sibling, 1 reply; 31+ messages in thread
From: Jason Rumney @ 2008-02-24 16:01 UTC (permalink / raw)
To: Miles Bader; +Cc: Chong Yidong, Eli Zaretskii, Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 15:39 ` Stefan Monnier
2008-02-24 15:44 ` Miles Bader
@ 2008-02-24 19:43 ` Eli Zaretskii
2008-02-24 23:04 ` Richard Stallman
2 siblings, 0 replies; 31+ messages in thread
From: Eli Zaretskii @ 2008-02-24 19:43 UTC (permalink / raw)
To: Stefan Monnier; +Cc: cyd, emacs-devel, jasonr
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 16:01 ` Jason Rumney
@ 2008-02-24 19:44 ` Eli Zaretskii
0 siblings, 0 replies; 31+ messages in thread
From: Eli Zaretskii @ 2008-02-24 19:44 UTC (permalink / raw)
To: Jason Rumney; +Cc: emacs-devel
> 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 `:'.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 15:23 ` Richard Stallman
@ 2008-02-24 20:01 ` Eli Zaretskii
2008-02-25 10:57 ` Richard Stallman
0 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2008-02-24 20:01 UTC (permalink / raw)
To: rms; +Cc: cyd, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 15:44 ` Miles Bader
2008-02-24 16:01 ` Jason Rumney
@ 2008-02-24 20:41 ` Stefan Monnier
2008-02-25 10:57 ` Richard Stallman
1 sibling, 1 reply; 31+ messages in thread
From: Stefan Monnier @ 2008-02-24 20:41 UTC (permalink / raw)
To: Miles Bader; +Cc: Eli Zaretskii, emacs-devel, Chong Yidong, Jason Rumney
>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 14:36 ` Jason Rumney
2008-02-24 15:39 ` Stefan Monnier
@ 2008-02-24 22:30 ` Richard Stallman
1 sibling, 0 replies; 31+ messages in thread
From: Richard Stallman @ 2008-02-24 22:30 UTC (permalink / raw)
To: Jason Rumney; +Cc: eliz, cyd, emacs-devel
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?
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 15:39 ` Stefan Monnier
2008-02-24 15:44 ` Miles Bader
2008-02-24 19:43 ` Eli Zaretskii
@ 2008-02-24 23:04 ` Richard Stallman
2008-02-24 23:44 ` Jason Rumney
2 siblings, 1 reply; 31+ messages in thread
From: Richard Stallman @ 2008-02-24 23:04 UTC (permalink / raw)
To: Stefan Monnier; +Cc: eliz, emacs-devel, cyd, jasonr
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 23:04 ` Richard Stallman
@ 2008-02-24 23:44 ` Jason Rumney
2008-02-25 19:01 ` Richard Stallman
0 siblings, 1 reply; 31+ messages in thread
From: Jason Rumney @ 2008-02-24 23:44 UTC (permalink / raw)
To: rms; +Cc: cyd, eliz, Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 20:01 ` Eli Zaretskii
@ 2008-02-25 10:57 ` Richard Stallman
2008-02-25 20:04 ` Eli Zaretskii
0 siblings, 1 reply; 31+ messages in thread
From: Richard Stallman @ 2008-02-25 10:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, emacs-devel
> 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'?
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 20:41 ` Stefan Monnier
@ 2008-02-25 10:57 ` Richard Stallman
2008-02-25 15:57 ` Stefan Monnier
0 siblings, 1 reply; 31+ messages in thread
From: Richard Stallman @ 2008-02-25 10:57 UTC (permalink / raw)
To: Stefan Monnier; +Cc: eliz, emacs-devel, jasonr, cyd, miles
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-25 10:57 ` Richard Stallman
@ 2008-02-25 15:57 ` Stefan Monnier
2008-02-26 12:36 ` Richard Stallman
0 siblings, 1 reply; 31+ messages in thread
From: Stefan Monnier @ 2008-02-25 15:57 UTC (permalink / raw)
To: rms; +Cc: eliz, emacs-devel, jasonr, cyd, miles
>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-24 23:44 ` Jason Rumney
@ 2008-02-25 19:01 ` Richard Stallman
2008-02-25 23:58 ` Jason Rumney
0 siblings, 1 reply; 31+ messages in thread
From: Richard Stallman @ 2008-02-25 19:01 UTC (permalink / raw)
To: Jason Rumney; +Cc: cyd, eliz, monnier, emacs-devel
# 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-25 10:57 ` Richard Stallman
@ 2008-02-25 20:04 ` Eli Zaretskii
2008-02-25 20:52 ` Andreas Schwab
0 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2008-02-25 20:04 UTC (permalink / raw)
To: rms; +Cc: cyd, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-25 20:04 ` Eli Zaretskii
@ 2008-02-25 20:52 ` Andreas Schwab
0 siblings, 0 replies; 31+ messages in thread
From: Andreas Schwab @ 2008-02-25 20:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, rms, emacs-devel
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."
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-25 19:01 ` Richard Stallman
@ 2008-02-25 23:58 ` Jason Rumney
2008-02-26 1:57 ` Stefan Monnier
0 siblings, 1 reply; 31+ messages in thread
From: Jason Rumney @ 2008-02-25 23:58 UTC (permalink / raw)
To: rms; +Cc: cyd, eliz, monnier, emacs-devel
[-- 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-25 23:58 ` Jason Rumney
@ 2008-02-26 1:57 ` Stefan Monnier
2008-02-26 3:41 ` Chong Yidong
2008-02-26 9:39 ` Jason Rumney
0 siblings, 2 replies; 31+ messages in thread
From: Stefan Monnier @ 2008-02-26 1:57 UTC (permalink / raw)
To: Jason Rumney; +Cc: cyd, eliz, rms, emacs-devel
> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-26 1:57 ` Stefan Monnier
@ 2008-02-26 3:41 ` Chong Yidong
2008-02-26 4:53 ` Stefan Monnier
2008-02-26 9:07 ` Jason Rumney
2008-02-26 9:39 ` Jason Rumney
1 sibling, 2 replies; 31+ messages in thread
From: Chong Yidong @ 2008-02-26 3:41 UTC (permalink / raw)
To: Stefan Monnier; +Cc: eliz, emacs-devel, rms, Jason Rumney
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.)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-26 3:41 ` Chong Yidong
@ 2008-02-26 4:53 ` Stefan Monnier
2008-02-26 9:07 ` Jason Rumney
1 sibling, 0 replies; 31+ messages in thread
From: Stefan Monnier @ 2008-02-26 4:53 UTC (permalink / raw)
To: Chong Yidong; +Cc: eliz, emacs-devel, rms, Jason Rumney
>>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-26 3:41 ` Chong Yidong
2008-02-26 4:53 ` Stefan Monnier
@ 2008-02-26 9:07 ` Jason Rumney
1 sibling, 0 replies; 31+ messages in thread
From: Jason Rumney @ 2008-02-26 9:07 UTC (permalink / raw)
To: Chong Yidong; +Cc: eliz, Stefan Monnier, rms, emacs-devel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-26 1:57 ` Stefan Monnier
2008-02-26 3:41 ` Chong Yidong
@ 2008-02-26 9:39 ` Jason Rumney
2008-02-26 15:18 ` Stefan Monnier
1 sibling, 1 reply; 31+ messages in thread
From: Jason Rumney @ 2008-02-26 9:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: cyd, eliz, rms, emacs-devel
[-- 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-25 15:57 ` Stefan Monnier
@ 2008-02-26 12:36 ` Richard Stallman
0 siblings, 0 replies; 31+ messages in thread
From: Richard Stallman @ 2008-02-26 12:36 UTC (permalink / raw)
To: Stefan Monnier; +Cc: eliz, emacs-devel, jasonr, cyd, miles
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem
2008-02-26 9:39 ` Jason Rumney
@ 2008-02-26 15:18 ` Stefan Monnier
0 siblings, 0 replies; 31+ messages in thread
From: Stefan Monnier @ 2008-02-26 15:18 UTC (permalink / raw)
To: Jason Rumney; +Cc: cyd, eliz, rms, emacs-devel
> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2008-02-26 15:18 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-23 22:00 [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem Chong Yidong
2008-02-23 22:22 ` Eli Zaretskii
2008-02-23 22:30 ` Chong Yidong
2008-02-23 22:33 ` David Kastrup
2008-02-24 4:16 ` Eli Zaretskii
2008-02-24 14:36 ` Jason Rumney
2008-02-24 15:39 ` Stefan Monnier
2008-02-24 15:44 ` Miles Bader
2008-02-24 16:01 ` Jason Rumney
2008-02-24 19:44 ` Eli Zaretskii
2008-02-24 20:41 ` Stefan Monnier
2008-02-25 10:57 ` Richard Stallman
2008-02-25 15:57 ` Stefan Monnier
2008-02-26 12:36 ` Richard Stallman
2008-02-24 19:43 ` Eli Zaretskii
2008-02-24 23:04 ` Richard Stallman
2008-02-24 23:44 ` Jason Rumney
2008-02-25 19:01 ` Richard Stallman
2008-02-25 23:58 ` Jason Rumney
2008-02-26 1:57 ` Stefan Monnier
2008-02-26 3:41 ` Chong Yidong
2008-02-26 4:53 ` Stefan Monnier
2008-02-26 9:07 ` Jason Rumney
2008-02-26 9:39 ` Jason Rumney
2008-02-26 15:18 ` Stefan Monnier
2008-02-24 22:30 ` Richard Stallman
2008-02-24 15:23 ` Richard Stallman
2008-02-24 20:01 ` Eli Zaretskii
2008-02-25 10:57 ` Richard Stallman
2008-02-25 20:04 ` Eli Zaretskii
2008-02-25 20:52 ` Andreas Schwab
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.