4:52 p.m.
Hi,
directory-files includes ".." when given the FILES-ONLY flag:
(member ".." (directory-files "~" nil nil nil t))
=> non-nil
This is with XEmacs 21.4.18 on Windows. 21.5.21 on Linux returns nil.
-- René
8:10 p.m.
René Kyllingstad <listmailxemacs(a)kyllingstad.com> writes:
Hi,
directory-files includes ".." when given the FILES-ONLY flag:
(member ".." (directory-files "~" nil nil nil t))
=> non-nil
This is with XEmacs 21.4.18 on Windows. 21.5.21 on Linux returns nil.
XEmacs 21.5 (beta23) "daikon" (+CVS-20051031) [Lucid] (i586-pc-win32, Mule) of
Tue Nov 01 2005 on TANG
which is a native Windows build on XP SP2 also returns nil.
-- René
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
4:43 a.m.
Adrian Aichner wrote:
René Kyllingstad <listmailxemacs(a)kyllingstad.com> writes:
>Hi,
>
>directory-files includes ".." when given the FILES-ONLY flag:
>
> (member ".." (directory-files "~" nil nil nil t))
>
> => non-nil
>
>This is with XEmacs 21.4.18 on Windows. 21.5.21 on Linux returns nil.
>
>
XEmacs 21.5 (beta23) "daikon" (+CVS-20051031) [Lucid] (i586-pc-win32, Mule) of
Tue Nov 01 2005 on TANG
which is a native Windows build on XP SP2 also returns nil.
i don't see anything obvious in mswindows_stat that might cause this;
not much has changed between 21.4 and 21.5.
6:59 a.m.
* Ben Wing:
Adrian Aichner wrote:
>René Kyllingstad <listmailxemacs(a)kyllingstad.com> writes:
>
>>directory-files includes ".." when given the FILES-ONLY flag:
>>
>> (member ".." (directory-files "~" nil nil nil t))
>>
>> => non-nil
>>
>>This is with XEmacs 21.4.18 on Windows. 21.5.21 on Linux returns nil.
>XEmacs 21.5 (beta23) "daikon" (+CVS-20051031) [Lucid]
(i586-pc-win32,
>Mule) of Tue Nov 01 2005 on TANG
>
>which is a native Windows build on XP SP2 also returns nil.
i don't see anything obvious in mswindows_stat that might cause
this;
not much has changed between 21.4 and 21.5.
I'm sorry, it's a more limited bug than I thought. It seems to only happen
with a root directory, for example:
(make-directory "c:/foo/bar/baz/" t)
(directory-files "c:/foo" nil nil nil t)
=> ("..")
(directory-files "c:/foo/bar" nil nil nil t)
=> nil
(first (file-attributes (first (directory-files "c:/foo" t nil nil t))))
=> t
so file stat *does* at some level recognize it as a directory.
-- René
11:04 a.m.
René Kyllingstad wrote:
* Ben Wing:
> Adrian Aichner wrote:
>
>
>
>>René Kyllingstad <listmailxemacs(a)kyllingstad.com> writes:
>>
>>
>>
>>>directory-files includes ".." when given the FILES-ONLY flag:
>>>
>>> (member ".." (directory-files "~" nil nil nil t))
>>>
>>> => non-nil
>>>
>>>This is with XEmacs 21.4.18 on Windows. 21.5.21 on Linux returns nil.
>>>
>>>
>>XEmacs 21.5 (beta23) "daikon" (+CVS-20051031) [Lucid] (i586-pc-win32,
>>Mule) of Tue Nov 01 2005 on TANG
>>
>>which is a native Windows build on XP SP2 also returns nil.
>>
>>
> i don't see anything obvious in mswindows_stat that might cause this;
> not much has changed between 21.4 and 21.5.
>
>
I'm sorry, it's a more limited bug than I thought. It seems to only happen
with a root directory, for example:
(make-directory "c:/foo/bar/baz/" t)
(directory-files "c:/foo" nil nil nil t)
=> ("..")
(directory-files "c:/foo/bar" nil nil nil t)
=> nil
(first (file-attributes (first (directory-files "c:/foo" t nil nil t))))
=> t
so file stat *does* at some level recognize it as a directory.
you could try (file-attributes "c:/foo/..") but that might not give you
much of use since file-attributes expand-file-name first.
what you really need to do is put a breakpoint on mswindows_stat() just
before calling (directory-files "c:/foo") and see what happens when
".."
comes up.
ben
3:45 p.m.
* Ben Wing:
René Kyllingstad wrote:
> (first (file-attributes (first (directory-files "c:/foo" t nil nil
> t))))
>
> => t
>
> so file stat *does* at some level recognize it as a directory.
>
>
you could try (file-attributes "c:/foo/..") but that might not give you
much of use since file-attributes expand-file-name first.
what you really need to do is put a breakpoint on mswindows_stat() just
before calling (directory-files "c:/foo") and see what happens when
".."
comes up.
Right. What happens is:
The incoming name is "c:\foo\..". This remains unchanged until the rootdir
test:
/* Remove trailing directory separator, unless name is the root
directory of a drive or UNC volume in which case ensure there
is a trailing separator. */
len = strlen (name);
rootdir = (path >= name + len - 1
&& (IS_DIRECTORY_SEP (*path) || *path == 0));
this test fails (meaning rootdir is set to 0). This results in "c:\foo\.."
being passed to FindFirstFile() which returns an error code when passed a
rootdir, the error is returned to directory-files, which then in effect
assumes that it is not a directory.
-- René
6702
days inactive
6703
days old
5 comments
3 participants
participants (3)
-
Adrian Aichner -
Ben Wing -
René Kyllingstad