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

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

bug#33450: 26.1.90; NEWS entry for dired 'Z' is inaccurate


From: Mike Kupfer
Subject: bug#33450: 26.1.90; NEWS entry for dired 'Z' is inaccurate
Date: Wed, 21 Nov 2018 06:50:51 -0800

Eli Zaretskii wrote:

> > The 26.1.90 NEWS file has this (new) entry for Dired:
> > 
> >   *** The 'Z' command on a directory name compresses all of its files.
> >   It produces a compressed '.tar.gz' archive with all the files in the
> >   directory and all of its subdirectories.  For symmetry, 'Z' on a
> >   '.tar.gz' or a '.tgz' archive extracts all the archived files into a
> >   directory whose name is the archive name sans the '.tar.gz' or '.tgz'
> >   extension.  (This change was actually made in Emacs 26.1, but was not
> >   called out in its NEWS.)
> > 
> > The description of the unpacking case implies that the user will see the
> > described behavior for any .tar.gz or .tgz file.  In reality, 'Z' simply
> > unpacks the archive.  The described behavior only happens if the archive
> > is structured in a canonical way, e.g., if 'Z' was used to create the
> > .tar.gz file.
> > 
> > The wording should be changed, so as not to mislead the user about what
> > 'Z' does.  A user who misunderstands what 'Z' does could lose data due
> > to unanticipated overwrite when the archive is unpacked.  (Note that the
> > docstring for dired-do-compress says nothing about creating or unpacking
> > archive files.)
> 
> I don't think I understand.  Are you alluding to the case when the
> archive includes absolute file names, or file names that raise above
> the directory where the archive lives?  Or do you have some other case
> in mind?

The case I have in mind is where the contents of the archive are
unrelated to the name of the archive.  No absolute path or .. is
involved.  For example:

$ ls
foo.tar.gz
$ tar tfz foo.tar.gz 
a
b
c
# uncompress foo.tar.gz with 'Z'
$ ls
a  b  c  foo.tar.gz
$ 

Based on the NEWS entry, a directory "foo" should have been created and
populated with a, b, and c.  But that's not what happens, at least not
on my GNU/Linux system (Debian 9).

mike





reply via email to

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