Ticket #1952 (accepted defect) — at Version 9
mc cd foo.tar#utar does not handle POSIX ustar archives, only GNU tar vendor-specific/legacy ones
Reported by: | mirabilos | Owned by: | andrew_b |
---|---|---|---|
Priority: | major | Milestone: | 4.8.30 |
Component: | mc-vfs | Version: | master |
Keywords: | Cc: | miros-discuss@…, zaytsev, mrmazda@…, nerijus@…, szotsaki@… | |
Blocked By: | Blocking: | ||
Branch state: | merged | Votes for changeset: |
Description (last modified by andrew_b) (diff)
Hi,
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.
Change History
comment:1 Changed 15 years ago by andrew_b
- Status changed from new to accepted
- Owner set to andrew_b
- severity changed from no branch to on review
- Milestone changed from 4.7 to 4.7.3
comment:3 Changed 15 years ago by andrew_b
- severity changed from on rework to on review
Fixed extraction files from TAR archive.
comment:4 Changed 15 years ago by andrew_b
- severity changed from on review to on rework
There are problems with devices.
comment:5 Changed 15 years ago by andrew_b
- severity changed from on rework to on review
I hope that's all. :)
comment:6 Changed 15 years ago by mirabilos
I’m reading the unidiff… this now looks better, but the various tar
utilities’ output formats *also* differ:
GNU tar
tg@frozenfish:~ $ tar tzvf mksh_39.3.orig.tar.gz
-rw-r--r-- root/wheel 296033 2010-02-25 22:03 mksh-39.3.orig/mksh-R39c.cpio.gz
-rw-r--r-- root/wheel 11840 2010-01-28 16:22 mksh-39.3.orig/printf.c.1.14
paxtar (OpenBSD, MirBSD, maybe others; I have a Debian package):
tg@blau:~ $ tar tzvf mksh_39.3.orig.tar.gz
-rw-r--r-- 1 root wheel 296033 Feb 25 22:03 mksh-39.3.orig/mksh-R39c.cpio.gz
-rw-r--r-- 1 root wheel 11840 Jan 28 16:21 mksh-39.3.orig/printf.c.1.14
bsdtar (libarchive-based; native on FreeBSD, MidnightBSD and others):
mirabilos@stargazer:~ $ tar tzvf mksh_39.3.orig.tar.gz
-rw-r--r-- 0 root wheel 296033 Feb 25 22:03 mksh-39.3.orig/mksh-R39c.cpio.gz
-rw-r--r-- 0 root wheel 11840 Jan 28 16:22 mksh-39.3.orig/printf.c.1.14
There may very well be others, but these three are the most often
used – although, on FreeWRT, we have busybox tar (because one of the
libc functions paxtar uses seems to be broken with µClibc):
root@wlan1:~ # tar tvf mksh_39.3.orig.tar
-rw-r--r-- 0/0 296033 2010-02-25 23:03:39 mksh-39.3.orig/mksh-R39c.cpio.gz
-rw-r--r-- 0/0 11840 2010-01-28 17:22:12 mksh-39.3.orig/printf.c.1.14
And yes, I’m also the maintainer of mc on FreeWRT ;-)
comment:7 Changed 15 years ago by andrew_b
OK, I see.
What we can do?
- We can parse the output of tar --version and call the according function for each TAR utility (GNU, paxtar, bsdtar, ...) in new utar script.
- We can support all tar formats in binary (as is currently in MC), but it will enlarge the size of main MC file (for reference, the size of GNU tar binary is more than 200 kB).
- We can use some 3rd-party library or framework that supports tar archives:
- Something else
comment:8 follow-up: ↓ 9 Changed 15 years ago by mirabilos
Only GNU tar supports --long-options.
I see two ways:
Either support all formats (I see two "major" differences with two subtle
subformats each) in the vfs script, or detect which tar /bin/tar is at
configure time (e.g. by checking a minimal tar file, I can produce one
which is 2K in size) and patch the vfs script (using the .in mechanism
would be fine) and hardcode /bin/tar as $TAR.
We could whitelist the four supported output formats (also consider that
gid 0 can be root, wheel, or something else…) and reject unknowns, thus
getting people to send in the actual output THEY get. Locale settings may
be an issue with GNU software (and some other) too.
This would break cross compilation though.
Or we could just try to apply guesswork (for instance, uid/gid or
uid<whitespacespace>gid, and it doesn’t matter whether uid and gid are
numeric or not… just the time/date format is annoying – the ls(1)-like
format is something I loathe to parse, but you can relatively easily
check for it). FWIW:
tg@blau:~ $ tar tzvf /MirOS/dist/mir/mksh/mksh-R24.cpio.gz | head -1
-rw-r--r-- 1 root wheel 125442 Jul 6 2005 mksh/mksh.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.
If you want I could have a look at hacking this too; I have access to
Solaris, possibly HP-UX and AIX (if they get the lpar to boot/work again),
so I could test it on relatively many systems. I’d need to be pointed to
a specification of what exact arguments, input and output the vfs scripts
receive and are supposed to output though.
comment:9 in reply to: ↑ 8 Changed 15 years ago by andrew_b
- Description modified (diff)
Replying to mirabilos:
Only GNU tar supports --long-options.
Long options are not used in recent version of vfs script .
I see two ways:
[skip]
This would break cross compilation though.
Cross compilation wouldn't be broken.
I’d need to be pointed to
a specification of what exact arguments, input and output the vfs scripts
receive and are supposed to output though.
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!
Created 1952_branch. Parent branch is master.
changeset:ff37dc26d46f652538c34475fec3f2b9bc9aa536
In this branch, MC uses external TAR program instead of self parsing TAR archives. This branch also fixes #2201.