Behavior of directory-files on Windows

Behavior of directory-files on Windows

[Thierry Volpiatto]

Hi all,

could someone explain behavior of `directory-files' on windows:

If I do: 
(directory-files "c:/")
The "c:/." and "c:/.." candidates are omitted

However if I do (directory-files "x:/")
The "x:/." and "x:/.." candidates are present as expected.

So my question is, why "c:/." and "c:/.." are omitted in
(directory-files "c:/") ?

Did I miss something or it is a bug ?

Thanks.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Behavior of directory-files on Windows

[Juanma Barranquero]

On Thu, Dec 1, 2011 at 13:54, Thierry Volpiatto
<thierry.volpiatto@gmail.com> wrote:

> If I do:
> (directory-files "c:/")
> The "c:/." and "c:/.." candidates are omitted

Assuming C:/ is really the root of your Windows' installation drive,
it does not have the . and .. entries (try doing "dir /a:" in C:\ and
in a subdirectory). So they are not omitted, they just are not there.

> However if I do (directory-files "x:/")
> The "x:/." and "x:/.." candidates are present as expected.

What is X:/ in your system? A remote directory, a symlink, junction,
subst, a removable drive?

    Juanma

Re: Behavior of directory-files on Windows

[Thierry Volpiatto]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Thu, Dec 1, 2011 at 13:54, Thierry Volpiatto
> <thierry.volpiatto@gmail.com> wrote:
>
>> If I do:
>> (directory-files "c:/")
>> The "c:/." and "c:/.." candidates are omitted
>
> Assuming C:/ is really the root of your Windows' installation drive,
> it does not have the . and .. entries (try doing "dir /a:" in C:\ and
> in a subdirectory). So they are not omitted, they just are not there.
Ok, I see now, thanks.

>> However if I do (directory-files "x:/")
>> The "x:/." and "x:/.." candidates are present as expected.
>
> What is X:/ in your system? A remote directory, a symlink, junction,
> subst, a removable drive?

It is a special volume that is used by Virtualbox as a shared directory
between host and guest.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Behavior of directory-files on Windows

[Juanma Barranquero]

On Thu, Dec 1, 2011 at 16:17, Thierry Volpiatto
<thierry.volpiatto@gmail.com> wrote:

> It is a special volume that is used by Virtualbox as a shared directory
> between host and guest.

And I suppose "dir /a: X:\" shows . and .. ?

    Juanma

Re: Behavior of directory-files on Windows

[Thierry Volpiatto]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Thu, Dec 1, 2011 at 16:17, Thierry Volpiatto
> <thierry.volpiatto@gmail.com> wrote:
>
>> It is a special volume that is used by Virtualbox as a shared directory
>> between host and guest.
>
> And I suppose "dir /a: X:\" shows . and .. ?
Yes.

Bad to not have the same for "c:/" like here on Gnu/Linux with "/".

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Behavior of directory-files on Windows

[Juanma Barranquero]

On Thu, Dec 1, 2011 at 16:37, Thierry Volpiatto
<thierry.volpiatto@gmail.com> wrote:

> Bad to not have the same for "c:/" like here on Gnu/Linux with "/".

IMO, directory-files should return the real content of the directory,
and that's what it does.

If you're complaining that the Microsoft's and Linux' filesystems
aren't consistent with one another, well...

    Juanma

Re: Behavior of directory-files on Windows

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 1 Dec 2011 15:39:41 +0100
> Cc: emacs-devel@gnu.org
> 
> On Thu, Dec 1, 2011 at 13:54, Thierry Volpiatto
> <thierry.volpiatto@gmail.com> wrote:
> 
> > If I do:
> > (directory-files "c:/")
> > The "c:/." and "c:/.." candidates are omitted
> 
> Assuming C:/ is really the root of your Windows' installation drive,
> it does not have the . and .. entries (try doing "dir /a:" in C:\ and
> in a subdirectory). So they are not omitted, they just are not there.

Right.  DJGPP, the development environment used to build the DOS port
of Emacs, actually _invents_ these two entries in the root of each
drive, to avoid the unpleasant surprises like the one Thierry just
hit.

Re: Behavior of directory-files on Windows

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Date: Thu, 01 Dec 2011 16:17:14 +0100
> Cc: emacs-devel@gnu.org
> 
> > What is X:/ in your system? A remote directory, a symlink, junction,
> > subst, a removable drive?
> 
> It is a special volume that is used by Virtualbox as a shared directory
> between host and guest.

Then these entries come from the Unix host.

Re: Behavior of directory-files on Windows

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juanma Barranquero <lekktu@gmail.com>
>> Date: Thu, 1 Dec 2011 15:39:41 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> On Thu, Dec 1, 2011 at 13:54, Thierry Volpiatto
>> <thierry.volpiatto@gmail.com> wrote:
>> 
>> > If I do:
>> > (directory-files "c:/")
>> > The "c:/." and "c:/.." candidates are omitted
>> 
>> Assuming C:/ is really the root of your Windows' installation drive,
>> it does not have the . and .. entries (try doing "dir /a:" in C:\ and
>> in a subdirectory). So they are not omitted, they just are not there.
>
> Right.  DJGPP, the development environment used to build the DOS port
> of Emacs, actually _invents_ these two entries in the root of each
> drive, to avoid the unpleasant surprises like the one Thierry just
> hit.

So that would make sense to add these two entries to output of 
`directory-files', after all, one is able to do:
(find-file "c:/.") but when he list directory this file ("c:/.") is not
present.


-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Behavior of directory-files on Windows

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Date: Thu, 01 Dec 2011 16:17:14 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> > What is X:/ in your system? A remote directory, a symlink, junction,
>> > subst, a removable drive?
>> 
>> It is a special volume that is used by Virtualbox as a shared directory
>> between host and guest.
>
> Then these entries come from the Unix host.
Ah! yes, that's clear.  Thanks.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Behavior of directory-files on Windows

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Cc: Juanma Barranquero <lekktu@gmail.com>,  emacs-devel@gnu.org
> Date: Thu, 01 Dec 2011 18:34:17 +0100
> 
> one is able to do: (find-file "c:/.") but when he list directory
> this file ("c:/.") is not present.

That's because "c:/." is canonicalized to "c:/" before passing it to
the appropriate system APIs.  IOW, the above is not a proof that "."
should exist; every system does such canonicalization at some point.

Re: Behavior of directory-files on Windows

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Cc: Juanma Barranquero <lekktu@gmail.com>,  emacs-devel@gnu.org
>> Date: Thu, 01 Dec 2011 18:34:17 +0100
>> 
>> one is able to do: (find-file "c:/.") but when he list directory
>> this file ("c:/.") is not present.
>
> That's because "c:/." is canonicalized to "c:/" before passing it to
> the appropriate system APIs.  IOW, the above is not a proof that "."
> should exist; 
Sure, but that still obscure, as (file-exists-p "c:/.") return t.

> every system does such canonicalization at some point.

So why not doing it in Emacs?

I think adding both c:/. and c:/.. to listing of directory-files doesn't
arm.
It's what I did here (in anything) and it is nice feature IMO.
On GNU/Linux, having "." and ".." in (directory-files "/") is not a
problem.

Do you think this can create problems in some places?

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Behavior of directory-files on Windows

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Cc: lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 02 Dec 2011 11:46:48 +0100
> 
> I think adding both c:/. and c:/.. to listing of directory-files doesn't
> arm.
> It's what I did here (in anything) and it is nice feature IMO.
> On GNU/Linux, having "." and ".." in (directory-files "/") is not a
> problem.
> 
> Do you think this can create problems in some places?

It won't create problems if done thoroughly: you need to invent all of
the file-attributes for these fake entries, including such obscure
ones as number of links etc.  And you need to handle the cases where
there are real directory entries by those names, so as not to clobber
accurate information.

Re: Behavior of directory-files on Windows

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Cc: lekktu@gmail.com,  emacs-devel@gnu.org
>> Date: Fri, 02 Dec 2011 11:46:48 +0100
>> 
>> I think adding both c:/. and c:/.. to listing of directory-files doesn't
>> arm.
>> It's what I did here (in anything) and it is nice feature IMO.
>> On GNU/Linux, having "." and ".." in (directory-files "/") is not a
>> problem.
>> 
>> Do you think this can create problems in some places?
>
> It won't create problems if done thoroughly: you need to invent all of
> the file-attributes for these fake entries, including such obscure
> ones as number of links etc.  And you need to handle the cases where
> there are real directory entries by those names, so as not to clobber
> accurate information.
Ok, I see, thanks for this comment.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997