GNU bug report logs - #47058
28.0.50; Dired Z: insert-directory: Reading directory: No such file or directory, CrossLine_linux_x86

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: mvar.40k <at> gmail.com, mcenturion <at> fing.edu.uy, 47058 <at> debbugs.gnu.org, arthur.miller <at> live.com
Subject: bug#47058: 28.0.50; Dired Z: insert-directory: Reading directory: No such file or directory, CrossLine_linux_x86
Date: Tue, 21 Sep 2021 11:24:36 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Tue, 21 Sep 2021 06:32:42 +0200
> Cc: Marco Centurion - URI <mcenturion <at> fing.edu.uy>, 47058 <at> debbugs.gnu.org,
>  Arthur Miller <arthur.miller <at> live.com>
> 
> "Michalis V." <mvar.40k <at> gmail.com> writes:
> 
> > the big downside of this patch is that it adds another prompt when
> > pressing Z: User must now enter the extraction directory (for file
> > /tmp/test.tar.gz the suggested default will be /tmp/test/). And that
> > behavior change might step on some people's toes so i'm a bit reserved
> > if this is the correct approach to solving the particular problem.
> 
> I think the new behaviour makes sense -- uncompressing the way we've
> been doing (to the current dir) is pretty dangerous (because the
> archives can overwrite files).  So I've installed your patch in Emacs 28
> (with some trivial whitespace changes).

I disagree that this is the right solution.  It solves the scenario of
the original report, but at a price of introducing an annoying
regression and backward-incompatible behavior in other, more important
use cases.

Let me take an important example: the Emacs release tarballs.  The
tarball's file name is emacs-X.Y.tar.gz, and the file names inside
have a leading directory of "emacs-X.Y/".  The name of the archive is
not important -- you can rename it at will, and the files are still
supposed to unpack into a sub-directory called "emacs-X.Y" under the
directory where you invoke the unpacking command.

This change will now cause the files by default to be unpacked into
emacs-X.Y/emacs-X.Y/, which is not our intent when we produce the
tarball.  (Yes, the user can override the default, but since the
default is identical to the correct directory name, many users will
not understand that they will get the files inside a subdirectory of
the directory they are prompted for, and will accept the default, to
their cost.)

This default is what the MS-Windows Explorer does when extracting
files from an archive.  It makes people inadvertently extract files
into a directory different from what the archive producer intended.
It is in particular nasty when unpacking binary distributions, which
are supposed to put files into the standard tree starting at "/usr" or
"/usr/local".  It is sad to see this silly, if not dangerous, default
seep into Emacs.

The original report is a rare and obscure use case: a tarball without
a leading directory.  Such tarballs should be avoided; they are not
well-formed tarballs.  But the use cases into which the "fix"
introduces annoying and incompatible behavior are much more important,
as this affects uncompressing every tarball out there.  So on balance,
I'd say it is a regression.  We should definitely not make this an
unconditional behavior change.

The root cause of this mess is that 'Z' was designed as a toggle
command, to support unpacking archives that were compressed by 'Z'
itself.  So it assumes that the files in the directory have the same
leading directory as the name of the archive, but that does not have
to be the case for archives created outside Dired.

So I think the correct solution for this bug is to catch the error of
the missing directory, and instead present the user with an
informative message saying that the files were extracted into a
directory such-and-such.  Because otherwise 'Z' in the OP's use case
did TRT: it unpacks the file into the current directory, as instructed
by the archive, the only problem is the error it signals.  That
archives should not generally have file names without leading
directories is not our problem; using 'tar' or some other unpacking
command would produce the same result, and there's no reason Emacs
should work differently.  In fact, one could argue that Emacs should
work the same, to be consistent with those other methods of unpacking.

I don't think we should have this "solution" in Emacs 28.

Previous Next

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