Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
bengt CreditAttribution: bengt commentedComment #2
ronan CreditAttribution: ronan commentedI've no idea. I've never seen that before. This is the unix file system timestamp of the actual backup files?
Comment #3
ddease2 CreditAttribution: ddease2 commentedSame 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!
Comment #4
nicolap CreditAttribution: nicolap commentedSame here:
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.
Comment #5
ericdsd CreditAttribution: ericdsd commentedHi
this issue is still pending, entire site backups makes the file timestamp incorrect whatever option is selected for backup.
Comment #6
ranelpadon CreditAttribution: ranelpadon as a volunteer commentedI'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.
Comment #7
couturier CreditAttribution: couturier as a volunteer commented@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.