Maybe this has been asked before, but I couldn't find it. Why have all files and directories in the file backup a timestamp like "1970-01-01"?

Comments

bengt’s picture

bengt commented
Title: Filestamp in file backup » Timestamps in file backup
ronan’s picture

ronan commented
Status: Active » Postponed (maintainer needs more info)

I've no idea. I've never seen that before. This is the unix file system timestamp of the actual backup files?

ddease2’s picture

ddease2 commented

Same issue here on multiple D7 sites. Using 7.x-3.0. Time stamps of 1/1/70 4:13am on all files, but directories have today's date.

This happens with backups downloaded directly from site, as well as those that are automatically downloaded to my S3 server.

Any suggestions?

Thanks!

nicolap’s picture

nicolap commented

Same here:

[Global]
datestamp = "1447091069"
formatversion = "2011-07-02"
generator = "Backup and Migrate (http://drupal.org/project/backup_migrate)"
generatorversion = "7.x-3.x"

The date of .tar is right but all files and dirs inside .tar are dated 1970/01/01 09:13.
Tried with .zip and .gz format.

ericdsd’s picture

ericdsd commented

Hi
this issue is still pending, entire site backups makes the file timestamp incorrect whatever option is selected for backup.

ranelpadon’s picture

ranelpadon commented

I've been hit by this nasty bug also. Timestamps in the extracted files are the same: January 1, 1970. Then, I noticed that the issue is inconsistent across our various Drupal projects:

1. Project A (Drupal 7.34): the issue does happen.
2. Project B (Drupal 7.43): the issue does not happen.
3. Vanilla Installation (Drupal 7.54): the issue does not happen.

All of them are using Backup and Migrate 7.x-3.1 module. So, I tried double-checking/comparing the various Drupal settings and configs, especially those related to Date and Media/File Systems. Eventually, I reluctantly concluded that the culprit might be in the Drupal core layer. Using incremental updates in Drush and reviewing the Drupal changelog for some related fixes, I've pinpointed that the issue has been fixed in Drupal 7.42 (released on February 2016). Furthermore, based on the 7.42 changelog, this could be the fix:

Updated the Archive_Tar PEAR package to the latest 1.4.0 release, to fix bugs with tar file handling on various operating systems.

Bottom line: make sure that you have Drupal 7.42 or later to avoid/solve this issue.

couturier’s picture

couturier commented
Status: Postponed (maintainer needs more info) » Closed (outdated)

@ranelpadon it sounds like this problem is completely resolved if developers will upgrade to the most current versions of core and Backup and Migrate. Note that the newest 7.x-3.2 release was published yesterday, September 27, 2017.