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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 4197 <at> debbugs.gnu.org, lennart.borgman <at> gmail.com
Subject: bug#4197: 23.1;	error when try to run `server-start': directory .emacs.d/server is	unsafe
Date: Fri, 21 Aug 2009 21:28:44 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <4197 <at> emacsbugs.donarmstrong.com>, <lennart.borgman <at> gmail.com>
> Date: Fri, 21 Aug 2009 11:12:16 -0700
> 
> 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.

The variable does more than just influence server.el.  It makes
file-attributes more accurate, which has its own benefits, most
prominently in Dired.

> > Can you perhaps convert the drive to NTFS?
> 
> No. Is it a joke?

No, I tried to help you work around the problem (and get a better
filesystem while at that).

> This is not my personal laptop. This is the standard issue for my
> company.

I couldn't know that, could I?

> I think Emacs should be able to coexist and behave nicely with FAT32 - don't
> you?

I do, and it does -- mostly.

> 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.

The code in server.el assumes a Posix filesystem.  We are trying to
get it to work nicely on Windows, when some of these assumptions don't
hold.  IOW, no one specifically assumed users do not have FAT32.

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

It is a more or less common knowledge in the Posix world.  But I do
agree that the message text should be more self-explanatory.

> 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).

If the message is explicit enough, it will explain itself.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.