Marco Centurion - URI <mcenturion@fing.edu.uy> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Marco Centurion <mcenturion@fing.edu.uy> writes:
>>
>>> I can confirm that this bug is present and pretty easy to reproduce.
>>> Steps to reproduce:
>>>
>>> ----
>>> $ touch test1
>>> $ tar czf test.tar.gz test1
>>> $ rm test1
>>>
>>> In dired, press Z (`dired-do-compress`) when the point is on test.tar.gz
>>> ----
>> I just did all those steps in emacs -Q, and I can not confirm any errors. I
>> named files exactly as you show there, and decompressed file is correctly named
>> 'test1'.
>>
>> I tested in two different directories, you three shell commands from terminal
>> (st in my case), and Z from dired created correctly test1.
>>
>
> Yes, the file is correctly decompressed.  The original report is about
> an error message that shows up in the minibuffer "Reading directory: No
> such file or directory, test".  And that's what I was able to reproduce
> without having to download the file linked in the report, something that
> I guess a lot of people wouldn't want to do.
>
>> Press 'g'.
>
> I do that, I just thought that it's a bit of a weird behaviour that
> sometimes after pressing Z the dired buffer is consistent with what's
> actually in the directory and sometimes it's not.  That is all.
> Personally I wouldn't be opposed to reverting the buffer after every
> operation that modifies files, but I'm sure most would and with good
> reason.


hi,

i've had a look into this some weeks ago and only just now managed to
assemble something presentable. As Marco correctly noted, the
problem is not with just a single file - any .tar.[gz|xz|zst|bz2] that
contains just files (no directories) will give the reported error.
The culprit is what 'dired-compress' expects: it assumes that the
uncompression result will produce just a single file or directory.

For example a test-file.gz will produce test-file, emacs-27.2.tar.gz
will give emacs-27.2/ etc. A special case is with formats that support
output directory like zip: boing.zip will be extracted to boing/
no-questions-asked. But for tars like this:

for i in a b c;do touch $i;done
tar cvzf abc.tar.gz a b c

doing Z on abc.tar.gz causes 'dired-compress' to expect abc but the
result is 3 new files a b c (and thus the error is shown). I tried to
think of some way to fix this and i've ended up with the attached
patch. What it does is to basically ask the user where to extract the
contents of the archive (even for zip files, so that the Z behavior is
somehow similar). To make this work for tar files i've added the -C
parameter in 'dired-compress-file-suffixes/. I've also added a missing
.tar.bz2 suffix (until now .tar.bz2 would just be decompressed & not
extracted).

The main work is done on a new function 'dired-uncompress-file' which
contains part of the code of 'dired-compress-file' (which handles both
compress/uncompress actions).
I thought it would be cleaner to have separate functions for these two
(and perhaps the latter function should be renamed to something better)
i've also added some new tests for .tar.gz and .zip formats.

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.

finally there's a corner case that is not solved: in the above scenario
with abc.tar.gz when you uncompress you still need to hit 'g' to refresh
the dired buffer (but there's no error anymore so at least that's
something). A fix for this would require some refactoring on what
'dired-compress' expects, perhaps make it expect a list of
files/directories and not just a single one, plus some more thinking into
the 'dired-compress-file' compression part.

thanks,
Michalis