bug#819: closed by Eli Zaretskii <address@hidden> (bug#819: 23.0.60; group and owner "Everyone" - what's that about?)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 29 Aug 2008 11:44:07 -0700
> Cc: 
> 
> > It has been closed by Eli Zaretskii <eliz@gnu.org>.
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Eli 
> > Zaretskii <eliz@gnu.org> by replying to this email.
> 
> I don't agree. You closed this even before my reply to your mail, and I 
> replied
> immediately.

I closed it because it complained about Emacs showing "Everyone" as a
group name.  "Everyone" is a legitimate Windows group name, so the bug
as submitted is actually expected behavior on Windows.

If you want to complain about something else, please submit another
bug report, and please change the description of a bug; telling that
"Everyone" is some kid of artefact is simply incorrect, and I can do
nothing but close such bugs.

> You supposed that I had NTFS, which I do not.

No, I supposed you had FAT32.  I don't expect "Everyone" anywhere
else.  I just didn't explain myself clearly.

> It is a bug that `..' is treated differently from other Dired entries, and 
> only
> when it represents the top-level directory (e.g. c:\).

That's not what the code does.  There's no special case for `..'.

> It is only when `..' stands for the top-level directory that `Everyone 
> Everyone'
> appears. In all other cases, all Dired entries, including `..' entries, list 
> the
> owner as my user name and the group as `None'.

I don't see that on FAT32 volume to which I have access.

The code that reports user and group IDs uses fallbacks for when the
file security syscalls fail.  The fallback is to attribute the files
to the user who runs Emacs.  On FAT32 volumes the syscalls fail, so
what you see is our best shot on reporting something sensible.