[Borgbackup] (too) many modified files
Thomas Waldmann
tw at waldmann-edv.de
Wed Jun 21 06:54:49 EDT 2023
>>>>> Using mtime is a bit less safe, as weird applications can
>>>>> set it to arbitrary values.
>>>>
>>>> I expected that mtime is set by the file system →?
>>>
>>> It can be easily manipulated by a userspace program, e.g. via `touch`.
>>
>> isn't it the same with ctime? AFAICS e.g. chmod changes ctime, even if
>> there are no changes, or chown.
>
> ctime is set to the *current* time when a file is changed. However,
> mtime can be set to an *arbitrary* time by a userspace program.
> So you can edit a file, and then change the mtime to what it was
> before the edit. That's why it isn't as safe to use mtime to determine
> whether a file has changed.
>
> And some "weird" programs that do this are borg, tar, touch, some
> version control systems, etc.
>
> For example, when you untar a tar file, tar sets the mtime to the
> original mtime, while the ctime is set to the current time.
Exactly.
Would not consider restoring a file and metadata from some sort of
backup or version control "weird" though.
But there are really weird tools (from a backup tool's perspective):
There seem to be image (like jpeg) processing tools that read an image
file, modify it, write it back and then re-set the mtime to the
timestamp it was before this modification.
If a backup tool then would use only mtime to detect changes, it would
not consider the file changed and thus not back it up, which is bad.
This is why borg defaults to --files-cache=ctime,size,inode because the
ctime always gets updated if any change to a file is made and the app
can not "reset" the ctime.
When one is forced to use mtime (because ctime is not supported by the
filesystem or behaving weird), one can use --files-cache=mtime,size,inode.
The size and inode check would often still trigger even for such weird
tools, but there is already a small risk (like if some tool opens the
original file, overwrites it with different data of same length, then
resets mtime to previous value - then mtime,size,inode would all stay
same and the file would be considered unchanged by borg and the content
changes would not get backed up).
More information about the Borgbackup
mailing list