mc cd foo.tar#utar does not handle POSIX ustar archives, only GNU tar vendor-specific/legacy ones #1952
Comments
Created 1952_branch. Parent branch is master.
In this branch, MC uses external TAR program instead of self parsing TAR archives. This branch also fixes #2201. |
|
Fixed extraction files from TAR archive. |
There are problems with devices. |
I hope that's all. :)
Initial [fbacd863dd2d9ae65903954827ae7547699d64db] |
I’m reading the unidiff… this now looks better, but the various tar
GNU tar
tg@frozenfish:~ $ tar tzvf mksh_39.3.orig.tar.gz
paxtar (OpenBSD, MirBSD, maybe others; I have a Debian package):
tg@blau:~ $ tar tzvf mksh_39.3.orig.tar.gz
bsdtar (libarchive-based; native on FreeBSD, MidnightBSD and others):
mirabilos@stargazer:~ $ tar tzvf mksh_39.3.orig.tar.gz
There may very well be others, but these three are the most often
root@wlan1:~ # tar tvf mksh_39.3.orig.tar
And yes, I’m also the maintainer of mc on FreeWRT ;-) |
OK, I see.
What we can do?
|
Only GNU tar supports --long-options.
I see two ways:
Either support all formats (I see two "major" differences with two subtle
We could whitelist the four supported output formats (also consider that
This would break cross compilation though.
Or we could just try to apply guesswork (for instance, uid/gid or
tg@blau:~ $ tar tzvf /MirOS/dist/mir/mksh/mksh-R24.cpio.gz | head -1
This is the format I see with “old” files.
So I’d all be for the first way – support all of them in the vfs script. |
Replying to mirabilos:
Long options are not used in recent version of vfs script .
Cross compilation wouldn't be broken.
You can found that in MC source tree (lib/vfs/mc-vfs/extfs/README) or in installed MC in you system (/usr/libexec/mc/extfs.d/README or /usr/lib/mc/extfs.d/README).
Thanks! |
|
|
There is a re-implementation of tar script in Debian bugzilla:
Maybe you can steal something from there. |
Branch 1952_tar. Parent: master. |
Recent master contains modified VFS layer. Branch 1952_tar has been rebased. |
|
|
|
I've been extracting mozilla.org's Linux archives for two decades on various Gnu Linux distributions using MC exclusively, in virtually all cases the MC version packaged by the distro.
http://archive.mozilla.org/pub/firefox/releases/68.5.0esr/linux-x86_64/en-US/firefox-68.5.0esr.tar.bz2 2020-02-10 is the last version I was able to do this with successfully.
As of http://archive.mozilla.org/pub/firefox/releases/68.6.0esr/linux-x86_64/en-US/firefox-68.6.0esr.tar.bz2 2020-03-09 the destination has corrupted timestamps, 1970-01-01 for ordinary files, current date/time for directories, using 4.8.24 on Fedora 32, Debian Testing/Bullseye and openSUSE Tumbleweed.
Same problem with http://archive.mozilla.org/pub/firefox/releases/68.7.0esr/linux-x86_64/en-US/firefox-68.7.0esr.tar.bz2 2020-04-06. |
|
|
So, Suse people updated the script in mid-2018 and apparently it has been working well for quite some time. Andrew, what's your opinion? Is there a good reason (performance? availability on embedded w/o tar executable?) why we should keep our tar code?
If it makes more sense to keep our code, I wonder if we could steal somewhere a modern and clean implementation from all tar subformats floating around instead having an old unmaintained own implementation which probably was branched from whatever at some point... |
File extraction will be too slow (like an uzip). tar doesn't contain a list of files. To extract a file you should walk through archive to find it. To extract next file, you should walk through archive again. Again and again.
In the MC's tar implementation, position of all files are stored while archive reading and then used while file reading/extraction.
I'm working on update of tar -- I'm trying to sync it code with GNU tar one. But, unfortunately, haven't enough time for that. It's not trivial task because MC'tar is GNU tar approx. 25 years ago. |
Oh wow, thank you very much for the explanation. Yes, if you think that it's possible to sync up the code with GNU tar, this would be perfect. Hopefully if done right, later syncs will be much easier. One could also try to steal code from libarchive. No idea if it's any easier and/or better... |
|
Now tar of MC supports various extended headers (including long file names and sparse files). The implementation is taken from GNU tar. Please test.
Branch: 1952_tar |
This is awesome work! I wonder if the code can be organised somehow such that updates from GNU tar will be easier in the future by checking the diff and just stealing the code... |
|
Merged to master: [e5911c1]. |
|
|
Timestamps in tar archive are shown as "Jan 1, 1970".
Branch: 195_tar_timestamp |
|
Important
This issue was migrated from Trac:
mirabilosmiros-discuss@….org,zaytsev(@zyv),mrmazda@….net,nerijus@….sourceforge.net,szotsaki@….comHi,
please see http://www.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_06
for the specification of the POSIX ustar interchange format.
GNU cpio (-Hustar), paxtar, and GNU tar --format=ustar
all create archives of this format; bsdtar probably does
as well. However, I cannot cd#utar or “Enter” them in
both mc-4.6.1-16 (MirPorts) and mc_3:4.7.0-1 (Debian sid).
After looking at tar.c I think you only support the legacy
or vendor-specific/proprietary GNU tar archive format.
The new boot floppies of MirBSD as of today are ustar
archives, with the bootsector squeezed into an ustar
header and closely following the standard. Introspection
would be nice.
Note
Original attachments:
zaytsev(@zyv) onSep 29, 2020 at 7:56 UTCThe text was updated successfully, but these errors were encountered: