bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe
Date: Fri, 21 Aug 2009 11:55:27 -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.

I don't doubt that. I know that NTFS offers a good deal more in terms of file
security possibilities than does FAT32.

But if the default value of the variable is inappropriate for some platform
(disk format), then it should be changed - at least on that platform.

Can you not test for this (e.g. using code similar to what you asked me to
evaluate to test this), and set the default value accordingly?

Or perhaps (since a user can have multiple drives with different formats) the
code that uses this option should check whether a non-nil value makes sense for
the drive in question, before simply proceeding as it does today.

Anyway, I'm unfamilar with the implementation, and I'm no expert on this
subject, so I'll leave the bug fix to others. From a user point of view,
something needs to be fixed here; that's all.

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

No, I didn't say that you could have or should have. You asked, and I told you;
that's all.

I'm letting you know that (a) no, unfortunately, I cannot change the drive
format, (b) changing the drive format cannot be the general answer to the
problem, even if it might help some users sometimes, and (c) this is a
widespread policy, in at least some organizations, so this likely does not
represent an isolated case, even if it's the first reported case.

> > I think Emacs should be able to coexist and behave nicely 
> > with FAT32 - don't you?
> 
> I do, and it does -- mostly.

Clearly I meant including in this regard - the question at hand.

There is no reason to be defensive (if you are doing that) about a bug. I can
understand that the bug might be difficult to fix in the best way, and that
takes time.

In the meantime, something can perhaps be done as a preventive measure. If the
drive format for Windows could be tested, that might be a solution. If not, if
nothing else can be done in the immediate, then I would suggest changing the
default for at least all Windows users to nil. 

IOW, better to forego the bells and whistles while waiting for a real fix, and
to at least let users use emacsclient without customizing. In this meantime
period, the doc can let Windows users know that if they happen to have NTFS
storage, then they can get more bells and whistles by changing the value to
non-nil.

I can understand that a developer wants to show off new, enhanced behavior, but
that shouldn't be the default if it leads to fundamental problems. Users who
have NTFS can easily customize to get the enhanced behavior.

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

I understand. Good.

> IOW, no one specifically assumed users do not have FAT32.

I didn't think so. I imagine that it was just an oversight (implicit
assumption).

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

The world of Emacs users is not identical to the Posix world. Emacs doc should
not assume that Emacs users have all the "common knowledge" of the Posix world.

This needs to be documented, beyond the error message. Users need to know how to
use this, including, at least for now, how to use it with FAT32 vs NTFS.

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

The message explaining itself will be corrected when the message is corrected.

My concern is beyond the message: Providing the essential info in this bug
report to users. Thx.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]