[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