Extract Here fails to preserve timestamps for non-empty folders

Bug #1133663 reported by Ernie 07 on 2013-02-26
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
File Roller
Fix Released
Medium
file-roller (Ubuntu)
Low
Unassigned

Bug Description

Extract Here fails to preserve timestamps for non-empty folders.

This functionally WORKED in 12.04, got DESTROYED in 12.10 and has not been fixed in either 64-bit 3.5.0-25-generic #39~precise1-Ubuntu SMP Tue Feb 26 00:07:14 UTC 2013 or 64-bit 3.8.0-7-generic #15-Ubuntu SMP Thu Feb 21 20:07:18 UTC 2013

Since I make use of this functionally frequently each day, I have avoided 12.10 except to determine if certain bugs have been fixed.

I would appreciate having this ROADBLOCK to using 13.04 removed.

Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in file-roller (Ubuntu):
importance: Undecided → Low
Ernie 07 (ernestboyd) wrote :

Sebastian,

Bug 697756 was filed a couple of weeks ago but has not been acknowledged.

Perhaps 100% reproducible bugs offer little technical challenge and are therefore ignored.

Ernie 07 (ernestboyd) wrote :

This BUG manifests in 12.10, 13.04 and 13.10 but NOT in 12.04 Apparently this functionality is either considered perfect and/or not important enough to warrant QA regression testing.

When a non-empty directory gets extracted, its datetime stamp is immediately restored but recursive extraction of its content (files, folders, etc) will update that directory's datetime stamp with the time of extraction. In 12.04, the datetime stamp restoration was delayed until after all content had been extracted.

Until it gets fixed upstream (2013 perhaps), the following CLI command will allow proper extraction of a tar.bz2 archive:

tar --delay -xvf tar-archive-name

tar -xvf tar-archive-name MAY yield unpredictable results

My eyes have trouble seeing the double hypen in "--dash" as I type this, so I will refer to them as "hyphen hyphen".

"hypen hypen" delay is an acceptable abbreviation of the option "hypen hyphen" delay-directory-restore

Changed in file-roller (Ubuntu):
status: New → Triaged
Changed in file-roller:
importance: Unknown → Medium
status: Unknown → New
Ernie 07 (ernestboyd) wrote :

This BUG still exists in file-roller 3.8.3 (13.10 dev)
The bug report submitted to GNOME several months ago indicates NO activity which would lead one to believe that it is being ignored. Might there be a Ubuntu-centric workaround?

Changed in file-roller:
status: New → Fix Released
Ernie 07 (ernestboyd) wrote :

Please re-open this bug. I tested using a recent 13.10 and file-roller 3.9.90 and observed that extract here fails to delay directory restore causing EVERY non-empty extracted folder to assume the date/time of extraction.

I will attempt to attach a screenshot of the relevant portion of the GNOME file-roller 3.8.4 change log and a screenshot of a terminal window indicating stats on the OS in use, an ls -al of the iso used to install the OS and the current file-roller version.

Ernie 07 (ernestboyd) wrote :
Ernie 07 (ernestboyd) wrote :
Ernie 07 (ernestboyd) wrote :

Another data point.

In addition to failing via the right click extract here menu, the CLI file-roller -h command produces the same failure.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.