When displaying the dates of files saved in destinations, backup_migrate currently uses the ctime of the file. I would like to argue that the mtime is more useful. Attached is a very simple one-line patch to change the use of filectime() to filemtime().

ctime (last change) is basically immutable on unix-like systems and is set by the file system. One is normally only allowed to modify atime (last access) and mtime (last modified).

When using a revision control system while staging your site on a development server, the files copied down from elsewhere are all going to have identical ctime's. This is because they are all created more or less simultaneously by the RCS. Any attempts by the RCS or the user to "correct" the file times by changing mtime or atime are not seen by backup_migrate because it is watching ctime. The upshot is that when one uses descriptive names in the manual backup destination, there is no way to tell the order in which the backups were originally created.

I can't imagine that this is a common difficulty; but I think mtime is more useful. ctime will also change if the name of the file is changed; while mtime should more accurately continue to reflect the time when the file was originally created.

ctime is also used in files.inc to determine whether a file has aged out and should be deleted; but I left that one alone since it's arguable that if someone even sniffs at a file that the expiration clock should reset (it's arguable the other way too...)

Thanks for your time.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jshprentz’s picture

FileSize
39.07 KB

Using ctime instead of mtime led to the incorrect age values shown in the attached screenshot. After resuming backups on a test site, I found that year-old files were reported to have an age of 35 weeks. I am using Backup and Migrate 6.x-2.4.

e0ipso’s picture

Status: Active » Reviewed & tested by the community

I am maintainig Backup & Migrate Prune module and I also have a use case with this.

I create the files and alter dates as show in the code from the issue #1881384

In order to test properly I need to create a mockup file set and fake the dates of the backups. To do so I need to temporarily hack B&M to read the mtime. Since we are dealing with backups, and these are rarely modified, I think it would not be a great deal moving to filemtime().

The patch works for me. Marking as RTBC.

vegansupreme’s picture

Since I switched over to a Linux VPS, my backup dates/ages have been wrong. Every file appears to be less than 24hrs old. Switching from ctime to mtime fixed all the dates. This also allows Backup & Migrate Prune to work. I'm surprised no one else seems to have this issue. Are there any downsides to using mtime?

ronan’s picture

Version: 7.x-2.2 » 7.x-3.x-dev
Status: Reviewed & tested by the community » Closed (won't fix)

The latest branch stores the timestamp in a metadata file so it doesn't vary when files are copied and it can be modified by hand (or by script or whatever) when needed.

organicwire’s picture

Version: 7.x-3.x-dev » 7.x-2.x-dev
Status: Closed (won't fix) » Reviewed & tested by the community

I also encounted this problem. The patch fixed the issue for me.

Leaving this issue unfixed may be no good idea. There's lots of folks out there using BAM 2.x. So can't we get it into the 2.x branch?

ronan’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Fixed

Ok, committed. Thanks

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.