bug#18851: 24.4; emacs cannot be started if the current directory has been removed

[Vincent Lefevre]

On 2014-10-29 16:27:13 +0200, Eli Zaretskii wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  18851@debbugs.gnu.org
> > Date: Wed, 29 Oct 2014 08:57:16 -0400
[...]
> > So the current Emacs C code really has no way to access a directory/file
> > which is not accessible from the root directory.

The problem is precisely when Emacs is called on a absolute pathname.
Currently Emacs quits instead of working on this file.

I repeat that I'm NOT asking that Emacs should work with a pathname
relative to a removed directory.

> That's true, but my reading of the code is that the value of the
> directory where Emacs was started is used for the following:
> 
>   . the default-directory of *scratch*

IMHO, if the current directory no longer exists, the default-directory
of *scratch* can be nil.

>   . invocation-name and invocation-directory, if Emacs was invoked via
>     a relative file name, like "../foo/bar/emacs".
> 
> In the first case, we could try using nil instead, maybe not all hell
> will break lose.  The second case is rare even without the removal
> (and makes no sense to me).

emacs --eval '(setq default-directory nil) (find-file "~/out")'

fails, but I wonder why.

> But I'd still like to hear the real-life use case behind this report.

Well, it happens that the current directory is removed for some
reasons, either on purpose or because of some FS error (in particular
if the FS is remote). Now, I may have already an application running
with this current directory, for instance, a MUA. If I want to write
a mail, the MUA will start an editor on an absolute pathname, Emacs
in my case, with the same current directory. But Emacs cannot be
started, just because the current directory no longer exists, meaning
that I can't write my mail without restarting the whole application.

Note: in some cases, one can still use a wrapper to change the current
directory to an existing one, but this can be a bit dangerous in
general, because if there are relative pathnames, one can end up
with loading/writing an incorrect file instead of getting an error.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)