[opensuse-factory] MidnightCommander: long file-names in tar archives truncated
Hello, I have noticed a problem of MidnightCommander in tar archives containing long file-names or long path-name + file-name, e.g. resulting from nested sub-directories. It seems the length of the path-name + file-name is limited to 100 characters, longer names are truncated. They are displayed truncated in the mc panel, and when the file (or its parent directory in the archive) is copied out of the archive with F5 it will have a truncated name. Therefore deeply nested tar archives can not safely be un-tarred with mc. For "current versions" of mc I could not find such a bug mentioned. steps to reproduce: mkdir testdir echo test > "testdir/testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789.txt" tar cJf testdir.tar.xz testdir start mc, enter testdir.tar.xz the filename is limited to testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123 The tar archive itself is correct and tar xf correctly restores the full file-names. If the same directory tree is zipped and the zip archive is entered with mc the filename is not truncated. The problem seems to be specific for the "utar://" vfs of mc. The problem is observed with the mc packages included in 12.3 (mc-4.8.1.4-2.1.2) and also with 13.1M4/factory (mc-4.8.9-2.2). Regards, Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2013/8/22 dieter
Hello,
I have noticed a problem of MidnightCommander in tar archives containing long file-names or long path-name + file-name, e.g. resulting from nested sub-directories.
It seems the length of the path-name + file-name is limited to 100 characters, longer names are truncated. They are displayed truncated in the mc panel, and when the file (or its parent directory in the archive) is copied out of the archive with F5 it will have a truncated name. Therefore deeply nested tar archives can not safely be un-tarred with mc.
For "current versions" of mc I could not find such a bug mentioned.
steps to reproduce:
mkdir testdir echo test > "testdir/testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789.txt" tar cJf testdir.tar.xz testdir
start mc, enter testdir.tar.xz the filename is limited to testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123
The tar archive itself is correct and tar xf correctly restores the full file-names.
If the same directory tree is zipped and the zip archive is entered with mc the filename is not truncated. The problem seems to be specific for the "utar://" vfs of mc.
The problem is observed with the mc packages included in 12.3 (mc-4.8.1.4-2.1.2) and also with 13.1M4/factory (mc-4.8.9-2.2).
Other problem I found in the actual version included in 12.3, when I changed the network connection method from the traditional to Network Manager (to add as backup when is necessary a 3G modem), and now with the network managed via Network Manager, mc has a delay of more than 1 minute to open. With the network managed via the traditional method, the delay to start is about a second. Regards, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 22/08/13 19:31, Juan Erbes escribió: her problem I found in the actual version included in 12.3, when I
changed the network connection method from the traditional to Network Manager (to add as backup when is necessary a 3G modem), and now with the network managed via Network Manager, mc has a delay of more than 1 minute to open. With the network managed via the traditional method, the delay to start is about a second.
MC has nothing to do network management.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-08-22 20:22 (GMT-0400) Cristian Rodríguez composed:
Juan Erbes composed:
now with the network managed via Network Manager, mc has a delay of more than 1 minute to open. With the network managed via the traditional method, the delay to start is about a second.
MC has nothing to do network management..
MC does do a network or host probe of some kind that requires competent hosts and resolv.conf files in order to avoid a lengthy startup delay. Searching the various list archives will probably get more detail. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-08-23 04:32, Felix Miata wrote:
On 2013-08-22 20:22 (GMT-0400) Cristian Rodríguez composed:
now with the network managed via Network Manager, mc has a delay of more than 1 minute to open. With the network managed via the traditional method, the delay to start is about a second.
MC has nothing to do network management..
MC does do a network or host probe of some kind
Might be a separate issue, but might be the same you see: When you exit mc, it remembers which directory the file panels showed. When you now restart mc **or any other mc component**, it will do a scan of that directory (which is especially useless with mcedit/mcview which don't show any directory listing), which can cause significant startup delays -- the more so if the directory you were in is a network share, a large directory, or has gone out of cache, or any combination of these complicating factors. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-08-22 22:32 (GMT-0400) Felix Miata composed:
On 2013-08-22 20:22 (GMT-0400) Cristian Rodríguez composed:
Juan Erbes composed:
now with the network managed via Network Manager, mc has a delay of more than 1 minute to open. With the network managed via the traditional method, the delay to start is about a second.
MC has nothing to do network management..
MC does do a network or host probe of some kind that requires competent hosts and resolv.conf files in order to avoid a lengthy startup delay. Searching the various list archives will probably get more detail.
https://mail.gnome.org/archives/mc-devel/2013-March/msg00005.html describes 3 possible fixes, all about networking. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/22/2013 8:22 PM, Cristian Rodríguez wrote:
El 22/08/13 19:31, Juan Erbes escribió: her problem I found in the actual version included in 12.3, when I
changed the network connection method from the traditional to Network Manager (to add as backup when is necessary a 3G modem), and now with the network managed via Network Manager, mc has a delay of more than 1 minute to open. With the network managed via the traditional method, the delay to start is about a second.
MC has nothing to do network management..
Delay starting mc usually means $DISPLAY is set but not resolvable. Lot's of different ways to produce that situation. Including possibly because of a change made by one or another network manager. You were saying? -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-08-23 17:42, Brian K. White wrote:
El 22/08/13 19:31, Juan Erbes escribió: her problem I found in the actual version included in 12.3, when I
changed the network connection method from the traditional to Network Manager (to add as backup when is necessary a 3G modem), and now with the network managed via Network Manager, mc has a delay of more than 1 minute to open. With the network managed via the traditional method, the delay to start is about a second.
MC has nothing to do network management..
Delay starting mc usually means $DISPLAY is set but not resolvable.
A classic! But today, it is greatly diminished because $DISPLAY generally no longer contains a host portion - X forwarding is usually done via tunnel mechanisms where software can immediately resolve. There may still be latency in actually _opening_ the X connection, though that should be much much less than the timeout for when DISPLAY="unreachable-host:0" :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 22/08/13 15:19, dieter escribió:
mkdir testdir echo test > "testdir/testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789.txt" tar cJf testdir.tar.xz testdir
start mc, enter testdir.tar.xz the filename is limited to testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123
The tar archive itself is correct and tar xf correctly restores the full file-names.
If the same directory tree is zipped and the zip archive is entered with mc the filename is not truncated. The problem seems to be specific for the "utar://" vfs of mc.
The problem is observed with the mc packages included in 12.3 (mc-4.8.1.4-2.1.2) and also with 13.1M4/factory (mc-4.8.9-2.2).
Hrmm.. it might be some sort of primitive buffer overflow check or the plugin just shortens the filenames for display.. in any case, fill a bug report ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Thu, 22 Aug 2013, Cristian Rodríguez wrote:
El 22/08/13 15:19, dieter escribió:
mkdir testdir echo test > "testdir/testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789.txt" tar cJf testdir.tar.xz testdir
start mc, enter testdir.tar.xz the filename is limited to testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123
The tar archive itself is correct and tar xf correctly restores the full file-names. [..] The problem is observed with the mc packages included in 12.3 (mc-4.8.1.4-2.1.2) and also with 13.1M4/factory (mc-4.8.9-2.2).
Hrmm.. it might be some sort of primitive buffer overflow check or the plugin just shortens the filenames for display.. in any case, fill a bug report ;-)
==== mc-4.8.1.4/src/vfs/tar/tar.c ==== #define NAMSIZ 100 #define PREFIX_SIZE 155 ==== Maybe we should replace that by a script /usr/lib/mc/extfs.d/tar using GNU tar, pax or star ... (i.e. write that script and compile without ENABLE_VFS_TAR i.e. --disable-vfs-tar). I strongly doubt that you can just change those defines. Joerg Schilling probably knows ... -dnh -- The primary difference [...] is that the Java programm will reliably and obviously crash, whereas the C Program will do something obscure -- Java Language Tutorial -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Fri, 23 Aug 2013, Cristian Rodríguez wrote:
On 08/22/2013 10:58 PM, David Haller wrote:
==== mc-4.8.1.4/src/vfs/tar/tar.c ==== #define NAMSIZ 100
Hrmm.. why it does not use PATH_MAX ?
Judging from a quick glance a the .c file, it's used to parse the tar archive headers for filenames and construct (together with PREFIX_SIZE) paths. And as far as I gathered from that other thread, tar has a historical limit on filenames of those 100 bytes and needs POSIX (ustar, pax) (or incompatible?) GNU extensions to store names longer than that. The tar implementation in mc seems rather rudimentary. Also, that script should probably be named /usr/lib/mc/extfs.d/utar to keep consistency with current behaviour (and be based on uar, urar or uzip)... In the long run, the mc implementation should probably be enhanced. Ah, just found something in 'man 3pm Archive::Tar': ==== By default, "Archive::Tar" is in a completely POSIX-compatible mode, which uses the POSIX-specification of "tar" to store files. For paths greater than 100 characters, this is done using the "POSIX header prefix". Non-POSIX-compatible clients may not support this part of the specification, and may only support the "GNU Extended Header" functionality. [..] Note that GNU tar earlier than version 1.14 does not cope well with the "POSIX header prefix". If you use such a version, consider setting the $Archive::Tar::DO_NOT_USE_PREFIX variable to "true ==== Oh, and some useful URLs from that manpage: The GNU tar specification http://www.gnu.org/software/tar/manual/tar.html The PAX format specification http://www.opengroup.org/onlinepubs/007904975/utilities/pax.html A comparison of GNU and POSIX tar standards; http://www.delorie.com/gnu/docs/tar/tar_114.html GNU tar intends to switch to POSIX compatibility http://www.gnu.org/software/tar/manual/html_node/Formats.html The last has: ==== ustar Archive format defined by POSIX.1-1988 specification. It stores symbolic ownership information. It is also able to store special files. However, it imposes several restrictions as well: 1. The maximum length of a file name is limited to 256 characters, provided that the file name can be split at a directory separator in two parts, first of them being at most 155 bytes long. So, in most cases the maximum file name length will be shorter than 256 characters. 2. The maximum length of a symbolic link name is limited to 100 characters. [..] ==== And Jörg's star's README.otherbugs is also mentioned to list known issues and incompatibilities. Ok, now I'm quite sure that those defines in mc's src/vfs/tar/tar.c MUST NOT be changed ... So, I guess writing a (adapting one of the existing) mc-extfs scripts using GNU tar/pax/star is the best way to handle that limitation of mc. I have not checked mc upstrem though if they know about that limitation (I guess they do) and/or if they plan to change the current simplistic "vfs-tar" implementation. HTH, -dnh -- Monotheism is a gift from the gods. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Fri, 23 Aug 2013 08:02:16 +0200 schrieb David Haller:
Ok, now I'm quite sure that those defines in mc's src/vfs/tar/tar.c MUST NOT be changed ...
So, I guess writing a (adapting one of the existing) mc-extfs scripts using GNU tar/pax/star is the best way to handle that limitation of mc.
I have not checked mc upstrem though if they know about that limitation (I guess they do) and/or if they plan to change the current simplistic "vfs-tar" implementation.
I found this ticket upstream: https://www.midnight-commander.org/ticket/2201 which is some years old. according to tar --help ... --format=posix is the default in the default tar on openSUSE (at least 12.3 and newer), therefore creating archives with unlimited file name length. The trac ticket#2201 also mentions "... tar vfs will be reimplemented as extfs plugin based on gnu tar. ..." and "... the TarVFS is scheduled for total reimplementation ...". So - create a bugzilla ? Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
David Haller
Hello,
On Thu, 22 Aug 2013, Cristian Rodríguez wrote:
El 22/08/13 15:19, dieter escribió:
mkdir testdir echo test > "testdir/testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789.txt" tar cJf testdir.tar.xz testdir
start mc, enter testdir.tar.xz the filename is limited to testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123
The tar archive itself is correct and tar xf correctly restores the full file-names. [..] The problem is observed with the mc packages included in 12.3 (mc-4.8.1.4-2.1.2) and also with 13.1M4/factory (mc-4.8.9-2.2).
Hrmm.. it might be some sort of primitive buffer overflow check or the plugin just shortens the filenames for display.. in any case, fill a bug report ;-)
==== mc-4.8.1.4/src/vfs/tar/tar.c ==== #define NAMSIZ 100 #define PREFIX_SIZE 155 ====
These are POSIX.1-1099 defines, don't change then unless you like to completemy break all.
Maybe we should replace that by a script /usr/lib/mc/extfs.d/tar using GNU tar, pax or star ... (i.e. write that script and compile without ENABLE_VFS_TAR i.e. --disable-vfs-tar). I strongly doubt that you can just change those defines. Joerg Schilling probably knows ...
OK, it seems that my last mail was too quick as the filename is split into prefix and rest, but if you only support POSIX.1-1988, you cannot support path names that end in a name component that is longer than 100 chars. Up to the 1990s, people did not really have a problem with that but now that even Microsoft left filesystem stoneage, people use longer names and need tar support for that. The official way is to support POSIX.1-2001 enhencements, but this is not a trivial change. Anything that goes bejond supporting 100 + 155 is a larger change. But maybe, you like to have a look at /usr/share/mc/extfs.d/README and implement a wrapper to star. Star is a good choice as it supports many different archive types. BTW: I just see that /usr/share/mc/extfs.d/iso9660 is based on a very old isoinfo version. It would be much easier to use the build in find(1) via -find that is implemented using libfind. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Fri, 23 Aug 2013 10:19:47 +0200 schrieb Joerg Schilling:
But maybe, you like to have a look at /usr/share/mc/extfs.d/README and implement a wrapper to star. Star is a good choice as it supports many different archive types.
I have opened bnc#836558 There I have also attached a simple extfs "untar" using the installed tar (possibly also star - but I did not test this, and if it requires different commands or options it wont work) tested with the openSUSE default tar list and copyout are working rm, mkdir, rmdir are partly working (only uncompressed tar archives) copyin is partly working (only uncompressed tar archives, destination archive rootdir) Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Sat, 24 Aug 2013, dieter wrote:
Am Fri, 23 Aug 2013 10:19:47 +0200 schrieb Joerg Schilling:
But maybe, you like to have a look at /usr/share/mc/extfs.d/README and implement a wrapper to star. Star is a good choice as it supports many different archive types.
I have opened bnc#836558
There I have also attached a simple extfs "untar" using the installed tar (possibly also star - but I did not test this, and if it requires different commands or options it wont work)
Thanks. But you're not calling tar posixly correct (e.g. '$TAR xaOf', that should probably be '"$TAR" -x -a -f '. $ star xaOf star: Illegal option 'a' for compat mode. So, your script will fail if "$TAR" is 'star'. But upstream has wanted to implement utar as extfs for years.... I intend to have a go at it myself, but don't hold your breath and I may close above bnc as (i don't know as what, an upstream issue, WONTFIX, INVALID, whatever ;). Anyway, your attachment is much appreciated anyway. -dnh --
if anybody who broke a nightly build should pay on beer, the whole development department would be drunk I guess ;-) [...] over the last 2 weeks we would have been *very* drunk. -- > Ulrich Windl and Marcus Meissner -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sat, 24 Aug 2013 22:03:08 +0200 schrieb David Haller :
Thanks. But you're not calling tar posixly correct (e.g. '$TAR xaOf', that should probably be '"$TAR" -x -a -f '.
$ star xaOf star: Illegal option 'a' for compat mode.
So, your script will fail if "$TAR" is 'star'. after uploading it to bugzilla I realized that different *tar implementations probably will require different options. I tested only with GNU tar and used its info page for reference...
But upstream has wanted to implement utar as extfs for years.... I intend to have a go at it myself, but don't hold your breath and I may close above bnc as (i don't know as what, an upstream issue, WONTFIX, INVALID, whatever ;). for my purposes it is working now...
Anyway, your attachment is much appreciated anyway. you're welcome.
Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
David Haller
Hello,
On Sat, 24 Aug 2013, dieter wrote:
Am Fri, 23 Aug 2013 10:19:47 +0200 schrieb Joerg Schilling:
But maybe, you like to have a look at /usr/share/mc/extfs.d/README and implement a wrapper to star. Star is a good choice as it supports many different archive types.
I have opened bnc#836558
There I have also attached a simple extfs "untar" using the installed tar (possibly also star - but I did not test this, and if it requires different commands or options it wont work)
Thanks. But you're not calling tar posixly correct (e.g. '$TAR xaOf', that should probably be '"$TAR" -x -a -f '.
$ star xaOf star: Illegal option 'a' for compat mode.
So, your script will fail if "$TAR" is 'star'.
It will also fail with plain vanilla "tar" - it will not even work with gtar because neither tar nor gtar support an option "a". Star will list access time with -a, do you really like this? OK let us make a list: $TAR tvaf "$1" will not work for "a" $TAR raf "$1" "$2" will not work for "a" $TAR xaOf "$1" "$2" > "$3" will not work for "a" and AND "O" $TAR raf "$1" "$2" >/dev/null will not work for "a" $TAR --delete -af "$1" "$2" >/dev/null will not work for --delete and "a" "which" is a csh script and does not interact nicely with a Bourne Shell If you fix the options, you will fail at other places: --- Make sure that you will not assume that you may extend compresed archives mctarfs_list makes illegal assumptions on the list output gtar lists completely non-standard and non-reliable as it's list output was frequently changed across versions "tar" lists in a historic way that was never standardized star when used with -pax-ls will list in the way that was standardized for POSIX pax. mctarfs_copyin Be careful, this _appends_ a second copy of a file to an archive. mctarfs_rm --delete is not doable in-place with tar archives if you implement a FIFO for efficient archive handling. but this is gtar only anyway .... Note that appending to a tar archive will even work with real tapes, but removing things from an archive cannot be done on tapes. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sun, 25 Aug 2013 16:03:39 +0200
schrieb Joerg Schilling
So, your script will fail if "$TAR" is 'star'.
It will also fail with plain vanilla "tar" - it will not even work with gtar because neither tar nor gtar support an option "a". I tried with star 1.5 which is the version in openSUSE factory (and its gnutar). This version does not yet support xz compression. Besides, I noticed that the parameters and the output are very different from GNU tar. Probably different enough to make a separate extfs script for star, or at least to handle each case specific on the used *tar.
Star will list access time with -a, do you really like this?
OK let us make a list:
$TAR tvaf "$1" will not work for "a"
$TAR raf "$1" "$2" will not work for "a"
$TAR xaOf "$1" "$2" > "$3" will not work for "a" and AND "O"
$TAR raf "$1" "$2" >/dev/null will not work for "a"
$TAR --delete -af "$1" "$2" >/dev/null will not work for --delete and "a"
"which" is a csh script and does not interact nicely with a Bourne Shell
If you fix the options, you will fail at other places:
--- Make sure that you will not assume that you may extend compresed archives
mctarfs_list makes illegal assumptions on the list output gtar lists completely non-standard and non-reliable as it's list output was frequently changed across versions "tar" lists in a historic way that was never standardized star when used with -pax-ls will list in the way that was standardized for POSIX pax.
mctarfs_copyin Be careful, this _appends_ a second copy of a file to an archive.
mctarfs_rm --delete is not doable in-place with tar archives if you implement a FIFO for efficient archive handling. but this is gtar only anyway ....
Note that appending to a tar archive will even work with real tapes, but removing things from an archive cannot be done on tapes.
it is a good hint that adding or deleting from tar archives are risky operations. Probably its better not to support it at all in this extfs script. For compressed archives (maybe most common?) GNU tar (1.26) will reject modification. Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2013-08-25 16:33, dieter wrote:
I tried with star 1.5 which is the version in openSUSE factory (and its gnutar). This version does not yet support xz compression.
You do know that tar does not really have to support any compression, because that can just be done through other programs piped to/from tar, don't you? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sun, 25 Aug 2013 18:30:17 +0200 (CEST) schrieb Jan Engelhardt:
I tried with star 1.5 which is the version in openSUSE factory (and its gnutar). This version does not yet support xz compression.
You do know that tar does not really have to support any compression, because that can just be done through other programs piped to/from tar, don't you?
Yes, I know. But the "-a" option of GNU tar to auto-detect the used compression is very convenient. "-J" to use xz I consider also more convenient than to pipe the output through xz. This may be a matter of taste... A script would need logic to determine the compression type of an archive, maybe it even can not rely on the suffix, and then pipe it to the specific compression program. In another thread Jörg wrote that star has good detection of the file type - maybe this refers (also) to the compression type. Therefore I think the effort to pack this detection into a script makes no sense. This may again be a matter of taste... Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2013-08-25 18:47, dieter wrote:
I tried with star 1.5 which is the version in openSUSE factory (and its gnutar). This version does not yet support xz compression.
You do know that tar does not really have to support any compression, because that can just be done through other programs piped to/from tar, don't you?
Yes, I know. But the "-a" option of GNU tar to auto-detect the used compression is very convenient.
Uhm, GNU tar does not even need the -a option anymore. `tar -xf foo.tar.xz` works out of the box. (Don't remember when that featuret was added, but it's there in 12.3.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
dieter
Am Sun, 25 Aug 2013 18:30:17 +0200 (CEST) schrieb Jan Engelhardt:
I tried with star 1.5 which is the version in openSUSE factory (and its gnutar). This version does not yet support xz compression.
You do know that tar does not really have to support any compression, because that can just be done through other programs piped to/from tar, don't you?
Yes, I know. But the "-a" option of GNU tar to auto-detect the used compression is very convenient. "-J" to use xz I consider also more convenient than to pipe the output through xz. This may be a matter of taste...
In other words, this gtar option seems to be rather useless as nobody did ever complain about the fact that star does this always. BTW: Many people today still use gtar versions that do not include this gtar/-a Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt
On Sunday 2013-08-25 16:33, dieter wrote:
I tried with star 1.5 which is the version in openSUSE factory (and its gnutar). This version does not yet support xz compression.
You do know that tar does not really have to support any compression, because that can just be done through other programs piped to/from tar, don't you?
Correct, star introduced code for identifying certain compression methods into the archive recognition automate aprox. 17 years ago. But some other tar implementations copied this idea meanwhile. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
dieter
Am Fri, 23 Aug 2013 10:19:47 +0200 schrieb Joerg Schilling:
But maybe, you like to have a look at /usr/share/mc/extfs.d/README and implement a wrapper to star. Star is a good choice as it supports many different archive types.
I have opened bnc#836558
Could you send an URL please? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-08-25 13:46, Joerg Schilling wrote:
dieter <> wrote:
I have opened bnc#836558
Could you send an URL please?
Just prepend the opensuse bugzilla url. "https://bugzilla.novell.com/show_bug.cgi?id=..." + "836558" = "https://bugzilla.novell.com/show_bug.cgi?id=836558" - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIZ9vwACgkQtTMYHG2NR9VybgCaA7yYGLFnfV0enXdHbLHhOqq0 v+wAnR0pAWO2hQTLlb3lZ2aMKwPs3Nlk =CF0n -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-08-25 08:22 (GMT-0400) Carlos E. R. composed:
I have opened bnc#836558
Could you send an URL please?
Just prepend the opensuse bugzilla url.
"https://bugzilla.novell.com/show_bug.cgi?id=..." + "836558" = "https://bugzilla.novell.com/show_bug.cgi?id=836558"
I don't get why on this and other openSUSE lists so many people find it easier composing email to type: bnc#836558 than to cut & paste from the bug they were just looking at: https://bugzilla.novell.com/show_bug.cgi?id=836558 Is the goal to reduce likelihood that that reader will bother to look at the bug? A lot of bugs referenced this way that I might have had an interest in I won't open precisely because of a full URL absence. Every email app I've ever used (which isn't many) automatically linkifies anything that starts with http:// or ftp:// or other valid protocols. With a full URL, I click the URL and visit the report. Without, I click delete. I'm already annoyed enough that bugzilla.novell.com automatically logs me out at every opportunity, unlike every other tracker using Buzilla software that keeps me logged in at least as long as the browser window remains open. It's not a bank (high need for security). It's just a bug tracker (minimal need for security). -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2013-08-25 15:53, Felix Miata wrote:
On 2013-08-25 08:22 (GMT-0400) Carlos E. R. composed:
I have opened bnc#836558
Could you send an URL please?
Just prepend the opensuse bugzilla url.
"https://bugzilla.novell.com/show_bug.cgi?id=..." + "836558" = "https://bugzilla.novell.com/show_bug.cgi?id=836558"
I don't get why on this and other openSUSE lists so many people find it easier composing email to type:
bnc#836558
than to cut & paste from the bug they were just looking at:
With an url of that length, it takes almost an extra line in .changes files, one could argue. Other than that, it is supported to write bugzilla.novell.com/836558 as url. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez
El 22/08/13 15:19, dieter escribió:
mkdir testdir echo test > "testdir/testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789.txt" tar cJf testdir.tar.xz testdir
start mc, enter testdir.tar.xz the filename is limited to testname_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123
The tar archive itself is correct and tar xf correctly restores the full file-names.
If the same directory tree is zipped and the zip archive is entered with mc the filename is not truncated. The problem seems to be specific for the "utar://" vfs of mc.
The problem is observed with the mc packages included in 12.3 (mc-4.8.1.4-2.1.2) and also with 13.1M4/factory (mc-4.8.9-2.2).
Hrmm.. it might be some sort of primitive buffer overflow check or the plugin just shortens the filenames for display.. in any case, fill a bug report ;-)
mc before 4.0.14 did not support even symlinks mc may now be on a stete from around 1982. Before POSIX.1-1988 tar did only support filenames with max 100 chars. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Brian K. White -
Carlos E. R. -
Cristian Rodríguez -
David Haller -
dieter -
Felix Miata -
Jan Engelhardt -
Joerg Schilling -
Juan Erbes