GNOME Bugzilla – Bug 487012
file-roller causes gnu tar >= 1.19 to give warnings when creating tar-archives
Last modified: 2008-06-03 17:57:40 UTC
Please describe the problem: If you create a .tar archive in file-roller using gnu tar >= 1.19 it gives you the following warning: tar: This does not look like a tar archive tar: Error exit delayed from previous errors Steps to reproduce: 1. Archive -> New -> test.tar 2. Edit -> Add files... Add any file you want, makes no difference what file it is Actual results: The error-dialog appears Expected results: No error-dialog Does this happen every time? yes Other information: file-roller uses tar like this to do what i described: tar --force-local --no-recursion --no-wildcards -v -p -C /PATH/TO/FILE/TO/BE/ADDED -rf PATH/TO/ARCHIVE.tar -- FILE_TO_BE_ADDED Tar gives you the error on command-line, too if you do this. This also happens if you touch the .tar before running the command. To make this error-message go away you have to create a valid .tar archive before: tar --create --file=/PATH/TO/ARCHIVE.tar --files-from=/dev/null (without the /dev/null-part gnu tar would refuse to create an empty tar-archive)
Same error here under file-roller 2.20.1 and tar 1.19.
Created attachment 98158 [details] [review] Proposed patch The attached patch creates the archive if it doesn't exist already, this fixes the issue for me. I don't know the internals of file-roller, so maybe it would be possible to do it without a separate file test. Ok to commit?
(In reply to comment #2) Thanks for the patch. It fixes the issue for me.
(In reply to comment #2) > Created an attachment (id=98158) [edit] > Proposed patch > > The attached patch creates the archive if it doesn't exist already, this fixes > the issue for me. I don't know the internals of file-roller, so maybe it would > be possible to do it without a separate file test. > > Ok to commit? > I tried that patch, and now file-roller doesn't complain anymore but when I add a file to an existing tar.bz2 or tar.gz archive it removes the old contents and creates a new tar with the added file only.
patch applied to trunk, thanks.
Please reconsider, the patch as attached to this bug report and committed to fr-command-tar.c in SVN fixes the problem reported but breaks adding new files to an existing archive and causes irreversible data loss.
Created attachment 101685 [details] [review] Better patch The previous patch didn't work because it checked for the uncompressed filename: when adding a file to an existing archive 'filename.tar.{bz2,gz}' it checked for 'filename.tar' and as this file didn't ever exist, tar was always called with the "-cf" switch and created a new 'filename.tar' who then was compressed overwriting 'filename.tar.{bz2,gz}'. The attached patch reverses the logic: it checks for the existence of 'filename.tar.{bz2,gz}' and only if it doesn't exist it makes file-roller call tar with the '-cf' switch.
Created attachment 101687 [details] [review] Simpler patch Simpler patch, same effects.
(In reply to comment #8) > Created an attachment (id=101687) [edit] > Simpler patch > > Simpler patch, same effects. > This patch correctly resolved the issue in Comment #4 for me. Anyone can commit the patch to svn? (no need to reverse the already committed one)
patch commited.
I'm facing this bug in Gnome 2.20.2 and ArchLinux 64bits. I reported it here : http://bbs.archlinux.org/viewtopic.php?pid=312933 Sorry if I spam this bug :(
(In reply to comment #11) > I'm facing this bug in Gnome 2.20.2 and ArchLinux 64bits. I reported it here : > > http://bbs.archlinux.org/viewtopic.php?pid=312933 > > Sorry if I spam this bug :( > you need to apply http://bugzilla.gnome.org/attachment.cgi?id=98158 then http://bugzilla.gnome.org/attachment.cgi?id=101687 (Works on my ArchLinux 32bit build, so it should work on you 64build)
(In reply to comment #10) > patch commited. > This is a tar bug, not a file-roller one, please check: http://lists.gnu.org/archive/html/bug-tar/2007-12/msg00001.html http://bugs.kde.org/show_bug.cgi?id=151708 Please revert the modification Thanks
The patch (http://svn.gnome.org/viewvc/file-roller/tags/FILE_ROLLER_2_21_91/src/fr-command-tar.c?r1=2006&r2=2058&sortby=date) can cause _serious_ data loss for archive with many files. The observed effect is the following: For folders with many files, file-roller begins to compress and creates the file which starts growing. Then, suddenly the file is truncated and begins to grow again. This can repeat multiple times. The resulting tar archive contains only a fraction of the files which have been requested for inclusion. This happens to be the fraction compressed in the last "run" since the last file truncation. It might be not apparent to the user who readily deletes the original files, thinking that (s)he had just made a complete backup. This is especially fatal since file-roller is used by nautilus/seahorse to aggregate files before encrypting. Users will often delete the original files after having encrypted them. This can result in total data loss. The bug introduced by the patch above is due to the limitation of the size of the argument list which seems to be currently set to 2/3*_POSIX_ARG_MAX. If this length is exceeded (which is common for folders with long filenames and/or with many files), the originally intended behavior is to split the archive creation into multiple tar invocations. However, the above patch checks every time if the file is already present and adds the -c flag if it is. This forces tar to create a new archive upon EACH invocation, overwriting the archive contents of the previous runs!
I can confirm the problem. The fix shouldn't be too complicated (just check for base_dir + filename instead of filename alone), but since the new behavior of tar was recognized as a regression and reverted upstream, I think that the best option would be to revert to revision 2006 and trust the distros to provide a patched tar 1.19.
Created attachment 105861 [details] [review] tar-1.19-update-flag.patch I attach here the patch to be applied TO TAR for fixing this bug for users who refer to here because of this problem
(In reply to comment #15) > I can confirm the problem. The fix shouldn't be too complicated (just check for > base_dir + filename instead of filename alone), I fail to understand why this should fix the problem described by me in my last note. Can you elaborate? I have to add that this was the first time I looked on the file-roller source code in order to find an explanation for what I've observed. So maybe I'm missing something. The base dir and filename are equal in all runs. In the initial one (creating the file) and the subsequent runs added to circumvent the maximum argument length imposed by POSIX. The problem here is, that the -c flag must not be supplied in the subsequent tar invocations as they are intended to append files in addition to what is already there.
I don't have the time to test the code now, so the patch has been removed for the 2.21.92 release.
*** Bug 523040 has been marked as a duplicate of this bug. ***
Paolo, I think that you could close this as NOTGNOME
ok, closing...