Set directory modification time (using SetModTime)

Help and Support
1

Dear rclone and data knowledgeable people, please try to help, I am lost... and for quite a while.

I get surprising sync updates. In log i see lines from output as in the command below like:

2026/06/02 10:24:05 INFO  : <Folder location>: Set directory modification time (using SetModTime)

Where Folder location is a folder in a big tree. lines in the log above and below do not mention specifically this folder. Contents is compared to equal result.

The SetModTime triggers OneDrive to update the folder and that is not good, by far!

I am running rclone in a BAT file as below:


"%RCLONE_EXE%" sync ^
    "%SRC%" ^
    "%TARGET_DIR%" ^
    -vv ^
    --stats-file-name-length 0 ^
    --fast-list ^
    --log-file="%LOGFILE%"
    --stats 10s ^
    --size-only ^
    --modify-window 9999d ^
    --ignore-case-sync ^
    --ignore-errors ^
    --delete-during ^
    --track-renames ^
    --no-update-modtime ^
    --no-update-dir-modtime ^
    --filter-from "%FILTER_FILE%" ^
    --dry-run ^

The TARGET_DIR is in use by OneDrive, it syncs it at its leisure. During rclone execution, OneDrive can be running normally, be paused or not running - makes no difference. SetModTime shows up.
Both SRC and TARGET_DIR are local folders.

I was using only --size-only in the beginning.

rclone v1.74.2
- os/version: Microsoft Windows 11 Enterprise 24H2 24H2 (64 bit)
- os/kernel: 10.0.26100.8457 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.26.3
- go/linking: static
- go/tags: cmount
2

Hi @krakl

Thanks for the report. The short version is that --no-update-dir-modtime should be stopping directory SetModTime. That log line shouldn't be able to appear when the flag is actually in effect - so I think the flag isn't reaching rclone in this run.

Set directory modification time (using SetModTime) is logged from exactly one place in the code, and the very first thing that function does is check the flag and bail out early if it's set. The sync layer also turns off all directory-modtime work up front when --no-update-dir-modtime is present, before it ever talks to the backend. So if you're seeing that line, --no-update-dir-modtime wasn't applied for that run.

A couple of things make me suspect the command that ran isn't quite the one pasted:

  • --modify-window 9999d is invalid. --modify-window takes a Go duration, which doesn't understand the d (days) unit - only --max-age/--min-age-style flags do. As written, rclone should exit immediately with:
    Error: invalid argument "9999d" for "--modify-window" flag: ... unknown unit "d"
    If you want a huge window, use hours, e.g. --modify-window 1000000h.
  • The Windows ^ line-continuation is easy to break - a trailing space after a ^ silently drops every flag after it.

To see what parameters are making it to rclone can you grab the line rclone prints at the very start of the -vv log:

DEBUG : rclone: Version "..." starting with parameters [...]

That shows the exact arguments rclone actually parsed. If --no-update-dir-modtime (or others) isn't in that list, that's the problem.

One aside: --no-update-modtime only affects file modtimes on identical files; it has no effect on directories, so it's not doing anything for this case.

3

Thanks a lot for responding that quick!!

This is the fist line as -vv is set (i am replacing with SRC and DESTINATION the two folders as they are long...)

2026/06/02 11:02:19 DEBUG : rclone: Version "v1.74.2" starting with parameters ["C:\Program Files\rclone-v1.73.5\rclone.exe" "sync" "SRC" "DESTINATION" "-vv" "--stats-file-name-length" "0" "--fast-list" "--log-file=C:\TEMP\log.txt"]

So, yes after couple of ^ nothing further gets to rclone!!!

4

Ah yes, there is a ^ missing on the --log-file line