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.
Comment | File | Size | Author |
---|---|---|---|
#1 | screenshot.png | 39.07 KB | jshprentz |
backup_migrate-destinations-mtime.patch | 404 bytes | ericxb | |
Comments
Comment #1
jshprentz CreditAttribution: jshprentz commentedUsing 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.
Comment #2
e0ipsoI 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.
Comment #3
vegansupreme CreditAttribution: vegansupreme commentedSince 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?
Comment #4
ronan CreditAttribution: ronan commentedThe 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.
Comment #5
organicwire CreditAttribution: organicwire commentedI 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?
Comment #6
ronan CreditAttribution: ronan commentedOk, committed. Thanks