After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 590027 - file-roller will not update files
file-roller will not update files
Status: RESOLVED FIXED
Product: file-roller
Classification: Applications
Component: general
2.26.x
Other All
: Normal normal
: ---
Assigned To: Paolo Bacchilega
file-roller-maint
Depends on:
Blocks:
 
 
Reported: 2009-07-28 15:30 UTC by James
Modified: 2009-11-07 20:16 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Test archive 1 (193 bytes, application/x-compressed-tar)
2009-07-28 15:31 UTC, James
  Details
Test archive 2 (194 bytes, application/x-compressed-tar)
2009-07-28 15:31 UTC, James
  Details
Rough patch that I've been using (1.45 KB, patch)
2009-11-07 17:40 UTC, James
none Details | Review

Description James 2009-07-28 15:30:42 UTC
Please describe the problem:
file-roller will not update (overwrite) destination files when unpacking (at
least) a subset of an archive.

Steps to reproduce:
1. Create two archives containing some subfolders and files. arch-1.tar.bz2 and
arch-2.tar.bz2 attached are like this --- they contain

   arch-{12}/folder/file

respectively, where file contains the string "Version 1" or "Version 2".

2. Create a destination folder, e.g. "dest".
3. Open arch-1.tar.bz2 in file-roller. Navtigate into "arch-1", select "folder",
and extract it to "dest", with "Re-create folders" and "Overwrite existing" checked.
4. Check dest/folder/file reads "Version 1".
5. Repeat step 3 with arch-2.tar.bz2.
6. Check dest/folder/file. It still reads "Version 1", we'd expect "Version 2".

Actual results:
Files not updated.

Expected results:
Files updated.

Does this happen every time?
Yes.

Other information:
Comment 1 James 2009-07-28 15:31:07 UTC
Created attachment 139389 [details]
Test archive 1
Comment 2 James 2009-07-28 15:31:20 UTC
Created attachment 139390 [details]
Test archive 2
Comment 3 James 2009-11-07 11:06:23 UTC
This has been around since July last year and is still broken in file-roller-2.28.1-2.fc12.x86_64.
Comment 4 Paolo Bacchilega 2009-11-07 17:34:16 UTC
thanks for your bug report, I can reproduce the problem and I'm working on it now.
Comment 5 James 2009-11-07 17:39:29 UTC
Hi Paolo, I've done a bit of poking around myself. Now, I don't know too much about the internals of file-roller, but it seems that it extracts files to a temporary directory, and then moves them to their destination by issuing an "mv -f" command. However, this doesn't work if the source argument is a directory with
the same name as [a non-empty] one in the destination directory, which is what
happens in the case described above: file-roller issues

  mv -f <temp-dir>/arch-2/folder <path-to>/dest

But dest/folder already exists, and the move fails.

I've managed to get around this by altering move_files_to_dir() in fr-archive.c
to instead issue a "cp" command. However, since a directory is being passed as
the argument for cp, to control overwrite (i.e., prevent clobbering when
"Overwrite" is unchecked), I've had to add another argument to
move_files_to_dir() and move_files_in_chunks(): gboolean clobber. When true,
"-f" is added as a cp argument, but "-n" is added otherwise.

I'll attach all this as a patch. Note that I've not added anything in the way
of cleanup after the copying. And I my solution here may cause other problems
that I cannot foresee, and so my patch might be crap ;)
Comment 6 James 2009-11-07 17:40:02 UTC
Created attachment 147175 [details] [review]
Rough patch that I've been using
Comment 7 Paolo Bacchilega 2009-11-07 18:56:13 UTC
James,

thanks for the patch, I've applied a modified patch that uses cp when the destination folder already exists and mv otherwise.  mv is preferred for performance reasons.

The fix will go into the next software release.
Comment 8 James 2009-11-07 19:04:19 UTC
That's great to hear. I take it that in this case that the next release is version 2.28.2?
Comment 9 Paolo Bacchilega 2009-11-07 20:16:17 UTC
yes