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 697756 - file-roller 3.6.x delay-directory-restore failing during non-empty folder extraction
file-roller 3.6.x delay-directory-restore failing during non-empty folder ext...
Status: RESOLVED FIXED
Product: file-roller
Classification: Applications
Component: general
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: Paolo Bacchilega
file-roller-maint
Depends on:
Blocks:
 
 
Reported: 2013-04-10 19:37 UTC by Ernie_07
Modified: 2013-09-29 17:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample-tar file -- ignore the bugnumber on it. (51.74 KB, application/x-compressed-tar)
2013-09-29 12:31 UTC, Bjørn Lie
Details

Description Ernie_07 2013-04-10 19:37:12 UTC
file-roller 3.6.x delay-directory-restore failing during non-empty folder extraction

64-bit File-Roller 3.6.0 via 1210 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 fails

64-bit File-Roller 3.6.3 via 1304 3.8.0-16-generic #26-Ubuntu SMP Mon Apr 1 19:52:57 UTC 2013 fails

64-bit File-Roller 3.4.1 via 1204 3.5.0-26-generic #42~precise1-Ubuntu SMP Mon Mar 11 22:17:58 UTC 2013 functions correctly

1. Extract a tar.bz2 archive containing non-empty folders.
2. Date-time stamps will be restored BEFORE folder content.
3. Date-time stamp restoration should be delayed until after folder content is restored.

This failure causes the date-time stamp of each non-empty folder to be overwritten with the date and time that folder content was restored.
This failure can be reproduced 100% of the time using either the right-click menu extract option or the file-roller from the cli.

Apparently file-roller is NOT included in regression testing.
Comment 1 Ernie_07 2013-04-26 15:49:57 UTC
This BUG can also be reproduced 100% of the time when using the just-released 64-bit Ubuntu 13.04 Desktop.

A 100% reproducible bug should NOT languish for weeks before being confirmed.

Bug fixing is a numbers game and picking this sort of low hanging fruit facilitates better numbers!
Comment 2 Ernie_07 2013-08-07 04:54:13 UTC
This BUG also exits in file-roller version 3.8.3

Is the lack of response an indication that I should scrap the versions 3.6 and newer in favor of version 3.4?

a LONG term supported version that includes this bug would be LAME!!
Comment 3 Paolo Bacchilega 2013-08-17 10:21:51 UTC
This problem has been fixed in the development version. The fix will be available in the next software release. Thank you for your bug report.
Comment 4 Ernie_07 2013-09-04 06:12:46 UTC
The failure reported is 100% reproducible in Ubuntu-13.10 development with file-roller 3.9.90.  Failure can be reproduced via the right-click extract here menu option or via the CLI file-roller -h command.

Is it possible that the version that was fixed (3.8.4) was not the version that became (3.9.90)?
Comment 5 Paolo Bacchilega 2013-09-04 10:20:10 UTC
Actually the problem is still present in both versions when a folder is extracted after a file contained in it.  

I think I have fixed it now in the current development version, can you please test the current git version and see if it is fixed for you as well?
Comment 6 Ernie_07 2013-09-05 05:06:28 UTC
I did not have success creating a debian package from the gnome git 3.9.91 source. How can I get access to a debian package for testing?
Comment 7 Paolo Bacchilega 2013-09-05 07:23:54 UTC
you can try with jhbuild: https://developer.gnome.org/jhbuild/3.5/
Comment 8 Ernie_07 2013-09-08 00:49:46 UTC
Hi Paolo,

I seem to be hitting some roadblocks. Attempts to install Ubuntu 13.10 from the 2013-09_05 daily build resulted in errors but not a useable installation.  Attempts to install Ubuntu 13.10 from the 2013-09_07 daily build resulted in a hung PC.  So I can not predict when I might be able to test your fix.

The tar.bz2 archives that I have used to demonstrate the failure are simple in form. The directory structure used consists of a top-level directory containing a few directories and some files. Each of those directories contains some files.

tar -xvf appears to add a default --delay-directory-restore an thus restores the original date-time stamp to each directory after its content has been restored.

menu option extract here and CLI file-roller -h restore content but allow the date-time stamps on non-empty directories to remain set to extraction time instead of mimicking the behavior of tar by restoring original date-time stamps.
Comment 9 Bjørn Lie 2013-09-29 12:31:30 UTC
Created attachment 256017 [details]
sample-tar file -- ignore the bugnumber on it.


Hi Paolo, using openSUSE 13.1 BETA, with file-roller 3.10.0, extracting some tar files failes giving a popup saying that there was an error with setting change or axsess time -- invalid argument.

Reverting https://git.gnome.org/browse/file-roller/patch/?id=6c831b143dd08f3d6c3d1923ef5751222d21fc86 and https://git.gnome.org/browse/file-roller/patch/?id=047b195c61a23dd3ec8b69dff43c1a21792ce4b6

makes the problem go away.
Comment 10 Ernie_07 2013-09-29 17:09:20 UTC
Hi Paolo,

The directory timestamp problem that I reported appears to have been fixed in version 3.9.92 found in 64-bit Ubuntu 13.10 development (3.11.0-9-generic #16-Ubuntu SMP Fri Sep 27 15:08:11 UTC 201).

I archive clusters of directories as a means of isolating various parts of ongoing projects. Your work has made my life easier! Thank you.