sjt> Mike? Andy? Anybody? What's going on here? sjt> Problems with filenames (dired and completion) on Windows are sjt> the main thing now blocking promotion of 21.4 to stable. sjt> Please, let's get this fixed. Adrian, please try this patch to win32_readlink(): Index: src/realpath.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/realpath.c,v retrieving revision 1.7.2.2 diff -u -r1.7.2.2 realpath.c --- src/realpath.c 22 Aug 2002 10:58:34 -0000 1.7.2.2 +++ src/realpath.c 7 Oct 2002 05:37:19 -0000 ＠＠ -90,7 +90,7 ＠＠ assert (*name); /* Sort of check we have a valid filename. */ - if (strpbrk (name, "*?|<>\"") || strlen (name) >= MAX_PATH) + if (strpbrk (name, "|<>\"") || strlen (name) >= MAX_PATH) { errno = EIO; return -1; Note: this code has been in XEmacs since 21.2.38, so something else has caused the recent manifestation of bugs. I'm just taking a wild guess at what is triggering the error. I'm pretty sure this code does get called in xrealpath() in both native and Cygwin builds, but in different places. I don't know if this is on the right track to resolve this problem. Somebody is going to have to think about what "check we have a valid filename" means, I have no idea on Windows. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Hi Stephen, with this patch (file-truename "c:\\*.txt") leads "c:\\B-r-Backtrace.txt" (the first of my many *.txt files). XEmacs 21.1.14, however does not expand the wildcard: (file-truename "c:\\*.txt") "c:\\*.txt" Adrian sjt> Mike? Andy? Anybody? What's going on here? sjt> Problems with filenames (dired and completion) on Windows are sjt> the main thing now blocking promotion of 21.4 to stable. sjt> Please, let's get this fixed. Stephen> Adrian, please try this patch to win32_readlink(): Stephen> Index: src/realpath.c Stephen> =================================================================== Stephen> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/realpath.c,v Stephen> retrieving revision 1.7.2.2 Stephen> diff -u -r1.7.2.2 realpath.c Stephen> --- src/realpath.c 22 Aug 2002 10:58:34 -0000 1.7.2.2 Stephen> +++ src/realpath.c 7 Oct 2002 05:37:19 -0000 Stephen> ＠＠ -90,7 +90,7 ＠＠ Stephen> assert (*name); Stephen> /* Sort of check we have a valid filename. */ Stephen> - if (strpbrk (name, "*?|<>\"") || strlen (name) >= MAX_PATH) Stephen> + if (strpbrk (name, "|<>\"") || strlen (name) >= MAX_PATH) Stephen> { Stephen> errno = EIO; Stephen> return -1; Stephen> Note: this code has been in XEmacs since 21.2.38, so something else Stephen> has caused the recent manifestation of bugs. I'm just taking a wild Stephen> guess at what is triggering the error. I'm pretty sure this code does Stephen> get called in xrealpath() in both native and Cygwin builds, but in Stephen> different places. Stephen> I don't know if this is on the right track to resolve this problem. Stephen> Somebody is going to have to think about what "check we have a valid Stephen> filename" means, I have no idea on Windows. Stephen> -- Stephen> Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Stephen> My nostalgia for Icon makes me forget about any of the bad things. I don't Stephen> have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Andy> But FSF Emacs does I believe. I quite like the expansion Andy> behavior - will it break anything? Well, since it only returns one of several files, it's kinda nondeterministic isn't it? And what is it supposed to do if there is no file with a matching name? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

APA> with this patch APA> (file-truename "c:\\*.txt") APA> => "c:\\B-r-Backtrace.txt" APA> (the first of my many *.txt files). APA> XEmacs 21.1.14, however does not expand the wildcard: APA> (file-truename "c:\\*.txt") APA> => "c:\\*.txt" Thanks. Especially for the confirmation about 21.1.14, this is the same thing (modulo the drive-spec and directory-sep-char differences) that the Unix version does. I bet somebody "simplified" some function to not separate the directory path from the basename (which might be a glob), since file-truename is supposed to handle this. It looks to me like win32_readlink should return EINVAL, meaning "not a symlink", when passed "*.txt" or "?.txt". How about this patch? (Sorry to send you so many half-baked patches, Adrian, but I don't understand this stuff very well.) This is pretty bad style (somebody who understands what the code at ll. 117--137 is doing should fix this), but should DTRT. Except that (a) the author of the code seems to think that "readlink" is supposed to correct case, and that's not possible for a glob, and (b) as the comments say, this will not handle a symlink whose real name contains glob (or shell op) characters correctly. But neither of those is handled correctly in the existing code, anyway, so.... It looks like Cygwin (and Unix) readlink will, when passed "*.txt", actually try to find a directory entry for "*.txt". Since normally no such entry exists, Cygwin returns ENOENT (this is a documented return value for Linux) and thus does not invoke win32_readlink (see l. 156). Index: src/realpath.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/realpath.c,v retrieving revision 1.7.2.2 diff -u -r1.7.2.2 realpath.c --- src/realpath.c 22 Aug 2002 10:58:34 -0000 1.7.2.2 +++ src/realpath.c 8 Oct 2002 02:36:10 -0000 ＠＠ -90,9 +90,16 ＠＠ assert (*name); /* Sort of check we have a valid filename. */ - if (strpbrk (name, "*?|<>\"") || strlen (name) >= MAX_PATH) + /* #### can we have escaped shell operators in a Windows filename? */ + if (strpbrk (name, "|<>\"") || strlen (name) >= MAX_PATH) { errno = EIO; return -1; } + /* #### can we have escaped wildcards in a Windows filename? */ + else if (strpbrk (name, "*?")) + { + errno = EINVAL; /* this valid path can't be a symlink */ + return -1; + } -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

>>>>> "Stephen" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: APA> with this patch APA> (file-truename "c:\\*.txt") APA> => "c:\\B-r-Backtrace.txt" APA> (the first of my many *.txt files). APA> XEmacs 21.1.14, however does not expand the wildcard: APA> (file-truename "c:\\*.txt") APA> => "c:\\*.txt" Stephen> Thanks. Especially for the confirmation about 21.1.14, Stephen> this is the same thing (modulo the drive-spec and Stephen> directory-sep-char differences) that the Unix version Stephen> does. Stephen> I bet somebody "simplified" some function to not separate Stephen> the directory path from the basename (which might be a Stephen> glob), since file-truename is supposed to handle this. Stephen> It looks to me like win32_readlink should return EINVAL, Stephen> meaning "not a symlink", when passed "*.txt" or "?.txt". Stephen> How about this patch? APA> Hi Stephen, this patch leads APA> (file-truename "c:\\*.txt") APA> "c:\\*.txt" APA> Adrian APA> M-x recover-session APA> also works again, which was broken too. APA> I'll do more testing. And here are some new problems: Signaling: (file-error "Opening directory" "No such file or directory" "c:\\Users\\AichnerAd\\") directory-files("c:\\Users\\AichnerAd\\" t "^\\.newsrc-slave-" t nil) apply(directory-files ("c:\\Users\\AichnerAd\\" t "^\\.newsrc-slave-" t)) dired-handler-fn(directory-files "c:\\Users\\AichnerAd\\" t "^\\.newsrc-slave-" t) directory-files("c:\\Users\\AichnerAd\\" t "^\\.newsrc-slave-" t) gnus-master-read-slave-newsrc() gnus-group-get-new-news(nil) call-interactively(gnus-group-get-new-news) (directory-files "c:\\Users\\AichnerAd") Signaling: (file-error "Opening directory" "No such file or directory" "c:\\Users\\AichnerAd\\") directory-files("c:\\Users\\AichnerAd" nil nil nil nil) apply(directory-files ("c:\\Users\\AichnerAd" nil nil nil)) dired-handler-fn(directory-files "c:\\Users\\AichnerAd" nil nil nil) directory-files("c:\\Users\\AichnerAd") eval((directory-files "c:\\Users\\AichnerAd")) eval-interactive((directory-files "c:\\Users\\AichnerAd")) eval-last-sexp((4)) call-interactively(eval-last-sexp) (directory-files "~") Signaling: (file-error "Opening directory" "No such file or directory" "c:\\Users\\AichnerAd\\") directory-files("~" nil nil nil nil) apply(directory-files ("~" nil nil nil)) dired-handler-fn(directory-files "~" nil nil nil) directory-files("~") eval((directory-files "~")) eval-interactive((directory-files "~")) eval-last-sexp((4)) call-interactively(eval-last-sexp) Adrian APA> Best regards, APA> Adrian Stephen> (Sorry to send you so many half-baked patches, Adrian, Stephen> but I don't understand this stuff very well.) Stephen> This is pretty bad style (somebody who understands what Stephen> the code at ll. 117--137 is doing should fix this), but Stephen> should DTRT. Except that Stephen> (a) the author of the code seems to think that "readlink" Stephen> is supposed Stephen> to correct case, and that's not possible for a glob, and Stephen> (b) as the comments say, this will not handle a symlink Stephen> whose real name contains glob (or shell op) characters Stephen> correctly. But neither of those is handled correctly in Stephen> the existing code, anyway, so.... Stephen> It looks like Cygwin (and Unix) readlink will, when Stephen> passed "*.txt", actually try to find a directory entry Stephen> for "*.txt". Since normally no such entry exists, Cygwin Stephen> returns ENOENT (this is a documented return value for Stephen> Linux) and thus does not invoke win32_readlink (see Stephen> l. 156). Stephen> Index: src/realpath.c Stephen> =================================================================== Stephen> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/realpath.c,v Stephen> retrieving revision 1.7.2.2 Stephen> diff -u -r1.7.2.2 realpath.c Stephen> --- src/realpath.c 22 Aug 2002 10:58:34 -0000 1.7.2.2 Stephen> +++ src/realpath.c 8 Oct 2002 02:36:10 -0000 Stephen> ＠＠ -90,9 +90,16 ＠＠ Stephen> assert (*name); Stephen> /* Sort of check we have a valid filename. */ Stephen> - if (strpbrk (name, "*?|<>\"") || strlen (name) >= MAX_PATH) Stephen> + /* #### can we have escaped shell operators in a Windows filename? */ Stephen> + if (strpbrk (name, "|<>\"") || strlen (name) >= MAX_PATH) Stephen> { Stephen> errno = EIO; Stephen> return -1; Stephen> } Stephen> + /* #### can we have escaped wildcards in a Windows filename? */ Stephen> + else if (strpbrk (name, "*?")) Stephen> + { Stephen> + errno = EINVAL; /* this valid path can't be a symlink */ Stephen> + return -1; Stephen> + } Stephen> -- Stephen> Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp Stephen> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Stephen> My nostalgia for Icon makes me forget about any of the bad things. I don't Stephen> have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py APA> -- APA> Adrian Aichner APA> mailto:adrian＠xemacs.org APA> http://www.xemacs.org/ -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

I guess my question is, what is: file-truename("c:\\*.txt") supposed to do? Is it documented? andy

On Tue, 08 Oct 2002, Stephen J. Turnbull wrote: [...] Changing this will cause TRAMP to break in nasty ways, potentially, or code that relies on the glob expansion to break when used with TRAMP. Glob expansion and path canonicalization have also been distinct operations for a very long time under Unix; it's probably best to preserve that. ...the right thing to do is probably to extend `find-file' to be glob expansion when operating interactively, which will do what anyone who likes the expansion in `file-truename' really wants if they think about it.[1] Daniel Footnotes: [1] It has the added advantage of doing something I would like to see as well. :) -- Sometimes a neighbor whom we have disliked a lifetime for his arrogance and conceit lets fall a single commonplace remark that shows us another side, another man really; a man uncertain, puzzled and in the dark like ourselves. -- Willa Silbert Cather, _Shadows on the Rock_ (1873-1947)