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

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

bug#25458: 25.1; tar mode does not handle compressed archives without sp


From: Eli Zaretskii
Subject: bug#25458: 25.1; tar mode does not handle compressed archives without specific extensions
Date: Sat, 14 May 2022 09:15:19 +0300

> From: Francesco Potortì <pot@gnu.org>
> Date: Sat, 14 May 2022 00:25:36 +0200
> Cc: 25458@debbugs.gnu.org,
>       Lars Ingebrigtsen <larsi@gnus.org>
> 
> >Then I guess I don't understand what is the problem we are asked to
> >fix here.  Francesco, can you explain?
> 
> If I read foo.tar into Emacs, where foo.tar was created with
> 
> $ tar -Jcf foo.tar any.file.name
> 
> then Emacs does not recognise it as a tar file.  Instead, it should look at 
> it, understand that it is a compressed tar file, uncompress and parse it.  If 
> asked to save it after modification, it should compress it before saving, 
> using the same compression method that was used in the first place.

You could do that by using magic-mode-alist, I guess?  It's just a
matter of writing the FUNCTION to put into the association for the
magic signatures of the compression methods you want to support.

FWIW, I don't think Emacs should do this by default, because looking
at the file's contents before looking at its file-name extension will
slow down visiting files, and having a .tar file that is actually a
.tar.xz file is quite unusual in the wild.  So this sounds like your
personal preference, and therefore customizing magic-mode-alist for
you sounds like TRT to fulfill your personal needs.

> Compression would be transparent to Emacs if it relied on Tar for parsing the 
> tar file, because Tar manages compressed files transparently.  But since 
> Emacs parses the tar file itself, it should behave as Tar does, that is, 
> uncompress the file if it was compressed in the first place, and recompress 
> when saving it after editing.

I don't think it's a good idea for Emacs to require Tar for visiting
archives.  For starters, Tar is not always available, and when it is
available, it doesn't always support all the compression methods
people could use.  We could use bsdtar (from libarchive), which
supports every archive format and compression method under the sun,
but its availability is even less than that of Tar.

So I think what we have now hits a good balance between functionality
in the popular use cases and reliability.





reply via email to

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