Repository navigation
borg2: --files-cache=ctime,inode,size (windows) #7193
Description
borg usually defaults to --files-cache=ctime,inode,size.
on linux, this is the best way to determine a file has not changed since we cached information about it into the files cache. this is because ctime is the "inode change time" and is only under kernel control, so nothing can be "faked" there by userspace (like rolling back the time to hide a change or so).
on windows, ctime attribute is the file creation time, does not change and is thus pretty useless for this purpose.
because of that, test_file_status_cs_cache_mode is currently skipped on windows, but this can't be the final solution.
borg rather should use --files-cache=mtime,size on windows (not sure about inode).
Activity
[-]borg2: ctime (windows)[/-][+]borg2: --files-cache=ctime,inode,size (windows)[/+]ThomasWaldmann commentedon May 12, 2023
Usage of ctime could be a bug, needs checking.
ThomasWaldmann commentedon Jul 3, 2023
@RayyanAnsari btw, the skipped test is rather special, but the problem on windows is likely much worse:
as borg by default uses ctime (== creation time on windows), the files cache would not detect modified file as modified if they have still same size and same inode (for the current
--files-cache=ctime,size,inodedefault).thus, i guess any backup except the first one might miss data (in previously existing, but updated files) on windows.
guess we must use mtime instead of ctime on windows by default or do we have any other options?
would it even make sense to reject
ctimeusage in--files-cacheon windows as invalid on windows?https://docs.python.org/3/library/os.html#os.stat_result
RayyanAnsari commentedon Jul 6, 2023
We could either use mtime, or perhaps try to come up with a value for ctime using WinAPI functions like in cygwin and libuv
see also: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_file_network_open_information
ThomasWaldmann commentedon Jul 6, 2023
Interesting that there is also a changetime.
Would've been great to have that in
stat_result.st_ctimeand the creation time somewhere else...Guess without that using
mtimeby default would be simplest?RayyanAnsari commentedon Jul 10, 2023
note to self: check python/cpython#102149 and its future implications
ThomasWaldmann commentedon Jul 10, 2023
@RayyanAnsari interesting. but they noticed they can't just change the semantics of ctime even if that would be prettier / more consistent in the end. that's what one gets if one does it wrong in the beginning...
RayyanAnsari commentedon Jul 11, 2023
commit description:
python 3.14 seems quite a while away...
We could implement ctime ourselves and get rid of it when that comes - shouldn't be too hard with ctypes.
ThomasWaldmann commentedon Jul 13, 2023
It also depends on the filesystem. NTFS can do it, other filesystems?
Would be cool if we could implement that in a non-messy way (at just one place, e.g. in a own
os_statorborg_statwrapper aroundos.stat). I thought about just patching it intostat_result, but that is read-only and also its implementation and properties varies by OS.ThomasWaldmann commentedon Sep 23, 2024
Related: I just changed the files cache, so it stores both ctime and mtime.
hiijoshi commentedon Mar 22, 2026
Hi, I’d like to work on this issue.
From the discussion, it seems the main problem is that Borg’s default files-cache mode relies on ctime semantics that are useful on POSIX, but not on Windows where ctime is creation time.
I’ll inspect where the default files-cache mode is selected and how the cache/status tests are structured, then propose a focused fix for Windows along with tests.
Use mtime,size,inode files cache default on Windows, fixes borgbackup…
create: do not use ctime for the files cache on Windows, fixes borgba…
Merge pull request #10114 from ThomasWaldmann/files-cache-win32-7193