bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Drew Adams]

> Ah! a FAT32 filesystem!

You sound surprised. That's really not uncommon. ;-) Might even be more common
than NTFS.

> > If this is the same as #865, then I guess it is pretty old.
> 
> It's been on my TODO forever to fix this, and I even wrote some code
> towards that goal.  But the problem is not easy to crack, since
> Windows sometimes attribute files not to the user who created them,
> but to the Administrators group instead, and that doesn't go well with
> the Posix-at-heart code which triggers this error.  Eventually, we
> will need to add more code to file-attributes and to make-directory,
> so that Emacs could create really private directories on Windows.
> 
> > Dunno whether my laptop configuration (Windows XP SP3,
> > with FAT32 drive) is atypical or not.
> 
> It's the FAT32 thing that trips you.  It doesn't support Windows
> native security features, so every file is attributed to Everyone
> (user-id of zero).

OK, but FAT32 is very common. I wonder about the default for the variable being
non-nil, even after the bug is fixed, but especially before then.

> emacsclient wants to be sure the directory where
> it places its socket file cannot be written to by any other user, but
> the fact its owner is Everyone, not you, tells emacsclient that the
> directory isn't private.
> 
> Can you perhaps convert the drive to NTFS?

No. Is it a joke?

FWIW, when I had a personal machine, I used NTFS. This is not my personal
laptop. This is the standard issue for my company. My guess is that others,
beyond my company, are in the same boat. The answer is not to ask them to
convert their disk drives.

I think Emacs should be able to coexist and behave nicely with FAT32 - don't
you? If some extra Emacs features are not available for FAT32, so be it, but
using FAT32 should not prevent one from using Emacs (e.g. emacsclient).

> > If not, until the bug is fixed you might consider changing 
> > the default value to nil, since this stops users with a
> > similar config from using emacsclient at all (out of the box,
> > emacs -Q). Unless they know about the workaround, that is.
> 
> We never heard about the problem until now, since Emacs 23 was
> released (the original bug was reported long ago, when Emacs 23 was
> still in development).  So it seems the problem is not too frequent:
> the number of people who use emacsclient on a FAT32 volume or that
> belong to the local Administrators group is apparently low enough for
> this gotcha not to hit too frequently.

I wouldn't bet on that at all.

* Emacs 23 was just released. I never tried to use emacsclient - I did so in
order to follow a bug report (for my code, and unrelated to emacsclient, as it
turns out).

* FAT32 is very common.

* AFAIK, every user in my company belongs to the local Administrators group for
his/her machine (e.g. laptop), so that s?he can easily install stuff etc. Other
organizations might have similar policies.

It doesn't make sense to make the default behavior dependent on assuming that
users do not have FAT32 and are not in the local Administrators group. IMO.
That's a crippling assumption.

> > Without your help, I never would have guessed it. I don't 
> > even understand the error message, "The directory is unsafe"
> > - maybe that message could refer me to
> > a manual section explaining unsafe directories?
> 
> I will add this to PROBLEMS, and look into modifying the message.  I
> think the message text is not very clear even on Unix.  Thanks for
> pointing this out.

Beyond the message text, what does it mean? Where is this notion of "unsafe
directory" documented in the manuals?

I see in the Emacs manual a discussion of unsafe variables, but not of unsafe
directories. I see in the Elisp manual mention of unsafe variables and unsafe
functions, but nothing about unsafe directories.

I think this should be explained in the manual(s) - we shouldn't simply improve
the message (though that too should be done). It is especially important to
document things that concern safety (if this really does).

Thx - Drew