Is there anyway to force my remote to accept the modification time of the local directories? Because when setdirmodtime was added as a feature I didn't bother to add --no-update-dir-modtime and I wish I had

Help and Support
1

Everything in this post is about google drive.

Is there anyway to force my remote to accept the modification time of the local files? Because when setdirmodtime was added as a feature I didn't bother to add --no-update-dir-modtime and I wish I had.

In rclone 1.63 my remote always just kept the directory modification time of whatever the local directory I was copying to the remote had. When I updated to rclone 1.72 however the directory modification time became the time of the upload I was making via rclone. I am much more concerned with the times of the real files being preserved than keeping track of the times I chose to execute rclone.

In theory I could just start using --no-update-dir-modtime
but I don’t actually want to not update the directory modtime, what I want to do is uh, set the remote directory’s metadata so that it’s modification time matches whatever the local modification time for that directory was.

Is this possible?

Only thing I can think to even try would be to go back to an older version of rclone but I do not think that will work, it will consider the newer directory modtimes on the remote “superior” most likely and not overwrite them.

TLDR: I want rclone to work so that if I copy a folder from my local hdd to the remote, then copy it back to another different hdd the modification time of the folder does not change. This is how rclone worked in 1.63 but in 1.72 by default it set all my directory’s modification times to today instead of whatever years old date they actually should’ve had. As far as I can tell it is too late to just use --no-update-dir-modtime as I need it to use setdirmodtime again only this time set the time to match the local directory’s modtime instead of whatever the current time is.

2

If this is simply impossible, maybe it could be a feature request, some new flag that did something for rclone copy and/or rclone move

–set-dir-modtime-source

And maybe that could do what I want. I can’t think of anyway to tell rclone to accept local folder modtimes, without just deleting the files on the remote. But in many cases the local folder is now missing it’s files, and I’ve merely kept the local directory structure to remind me what I can grab back from the cloud if I ever need to.

Ooof, maybe this is too fringe a use case to matter.

Although. I wonder. Is there anyway to edit the configuration file for rclone or my remote to make -no-update-dir-modtime ?

Because I cannot see myself ever wanting to not use that flag, and if I ever forget to use that flag, 1000s of directories will almost instantly lose their true modification time. Which is bad enough, that if I cannot learn a way to make -no-update-dir-modtime some sort of default mode in a config file, I’ll have to just use a wildly out of date version of rclone to protect myself from my own foolishness :frowning:

3

To explain my utterly looney stance…. I prefer when moving a folder from my D drive to my E drive does not cause the metadata for that folder to change and the modification time remains the same.

I view rclone and my remotes as a similar procedure. When new files are added to the local directory they get new dates, which I do want to update the time for on the remote. But I don’t want the remote to simply accept the time of “today” I want it to take the local modification time, since that’s the last time a true modification of the contents of the folder occurred.

Everything I do with rclone is basically a function of “backing up” something. So I only want rclone to set times on remotes that match source times. To keep things even. The current default behavior sets the time to the current time, treating the time I chose to run the command line backup as more important than the local times. Hmm.

I guess my reasoning here is why --no-update-dir-modtime exists, but, well, I not only want --no-update-dir-modtime to exist, but I need a way to heal all the remote folder modtimes if I forget to use --no-update-dir-modtime

In theory it’s not impossible, as the local directory still has it’s modification time, that time is just being ignored because either the time on the remote is newer, or maybe for some other reason I cannot comprehend. Sorry for explaining this so poorly.

TLDR: I am addicted to how windows explorer does things even if it does them badly :stuck_out_tongue:

4

Du musst dafĂĽr nicht bei einer alten Version bleiben. Du kannst fast jedes Rclone-Flag dauerhaft ĂĽber Umgebungsvariablen setzen, damit es zum Standard wird.

FĂĽge einfach export RCLONE_NO_UPDATE_DIR_MODTIME=true zu deiner Shell-Konfiguration (z.B. .bashrc oder .zshrc) hinzu. Dann wird das Flag bei jedem Befehl automatisch genutzt, ohne dass du daran denken musst.

5

I don't even understand your problem, partly maybe because of the number and amount of posts.

Copying or syncing a file to a remote SHOULD update their mod time to that of your local copy.

At least, this is how I remember it.

That may depend on the type of remote storage, but I cannot test with Google as I would never use anything from them (evil).

But I cannot test this again on other types of remote at the weekend, if that helps you.

6

Sure, feel free, that would help.

However the issue is that I want to take OLD source directory modtimes and use them to replace NEW remote directory modtimes.

The default behavior you speak of updates remote directory modtimes to match the local modtime IF the local modtime is newer, but to force an update of an OLDER modtime I do not know how to do. Also I am speaking only of directories not files.

edit: Also, yes, my incompetence is the cause of my problems, and my incompetence means I only halfway understand what rclone does, meaning I can only halfway explain myself. None the less people often manage to help me because the people on this forum are so knowledgeable :slight_smile:

TLDR: I freely admit that all of this issue is entirely due to my own mistakes, not rclone’s.

7

Hmm.

I am still not sure what you are trying.

Let me guess:

You have local source and remote target already in sync?

But somehow the mod times differ between local and remote?

Then, try to sync again from local to remote and use this options (not sure if they are enabled by default):

RCLONE_NO_UPDATE_MODTIME=false
RCLONE_USE_SERVER_MODTIME=false

I would imagine that this updates the remote mod times.

If that does not work, you may sadly need a new upload, by disabling the time check and using only checksum (another option).

I can test myself only at the weekend.

1 Like
8

when you posted, there was a template of questions??, that allows us to best help you

  • output of rclone config redacted
  • the exact command which includes the name of the remote
  • debug output of the command
9

Hmm, I don’t quite know how to explain it better…. the output is not the problem, it’s the result. Hmm.

I updated from rclone 1.63 to 1.72 and did not use --no-update-dir-modtime

Which set all my remote directories affected by a thankfully small rclone copy command to have a modtime of today (the day I did this.)

What tja suggested to me might work.

RCLONE_NO_UPDATE_MODTIME=false
RCLONE_USE_SERVER_MODTIME=false

This sounds like what I want to do, but I do not know the syntax to add a flag command with an equal sign to an rclone command.

This is what rclone config tells me, but I do not see how it matters?

cleancrypt crypt
googledrive drive

This is the same as me saying I am using google drive, which I do think I did mention?

tja seems to understand what I am saying, except I am using rclone copy instead of rclone sync. The cloud has more versions of files than the local source, the local source only has the current data, not the historical data, but the local source has the correct directory modification times, and the remote version is polluted with some directory modification times which I accidentally set to the time I was running an rclone command.

TLDR: How do I turn:
RCLONE_NO_UPDATE_MODTIME=false
RCLONE_USE_SERVER_MODTIME=false
into a valid .\rclone -v copy --more-options --that-somehow --use-an-equal-sign-to-set-something-false
syntax?

There is no exact command, and no debug output, because I have absolutely no idea what command to run.

To clarify I ran the wrong command in the past, the day I made this thread. I then instantly learned the correct command. I learned about the existence of --no-update-dir-modtime

My issue is that my remote has incorrect dates and using the correct command does not fix those dates. What I need is an alternate command like what TJA is suggesting to fix the directory modification times. And then to going forward not make my mistake again.

10

To be ultra simple and clear.

I ran this command:

C:\rclone-v1.63> .\rclone copy --RCLONE_USE_SERVER_MODTIME=false --RCLONE_NO_UPDATE_MODTIME=false -v “source:folder” “remote:folder”

I got this feedback.

Error: unknown flag: --RCLONE_USE_SERVER_MODTIME
Usage:
rclone copy source:path dest:path [flags]

This is what I expected because I am using the wrong syntax, but I never heard of these options before so I do not know how to make them real.

Of course I also tried:

.\rclone copy --RCLONE-USE-SERVER-MODTIME=false --RCLONE-NO-UPDATE-MODTIME=false

Which also didn't work, because as far as I can tell these are not real flags. But TJA seems to think this is possible, if it was possible, it might work, and it might solve my problem.

11

Something like

--refresh-times

Is actually close to what I want here, but as far as I can tell --refresh-times is files only not directories. Hmm. I am starting to think that what @tja suggested was theoretical and no such flag or option exists to do what I want. (force update modtimes from source to remote of directories.)

edit: I did try –refresh-times but as I expected it had no effect on directory’s modification times.

12

me too.

gdrive allows for the modification of modtime for directories.

rclone lsd d:\zork
           0 2027-02-02 16:54:21        -1 dir

rclone lsd gdrive:zork
           0 2026-02-02 16:54:21        -1 dir

rclone copy d:\zork gdrive:zork  -v
INFO  : dir: Set directory modification time (using SetModTime)
INFO  : There was nothing to transfer

Transferred:              0 B / 0 B, -, 0 B/s, ETA -
Checks:                 1 / 1, 100%, Listed 4
Elapsed time:         1.1s

@left1000, i know it can be hard to be concise but if you could, please explain what you need help with?
please just ONE single, very simple, very short sentence.

13

You should at least try to read the man page!

I never use command line options, always environment variables - therefor, I gave those that I use!

So, either set those variables and try again or read the manual and find the command line switches. They should be like the variables, but in lower case and without leading “rclone” in the names.

But READ the man page first!

Try “rclone —help”, or seek the documentation on the website, as you are on windows and “man rclone” may not work.

14

I tested it now:

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ export RCLONE_NO_UPDATE_MODTIME=false

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ export RCLONE_USE_SERVER_MODTIME=false

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ date > TESTFILE

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ rclone sync /Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED S3_WEBDAV_TJA:CONTENT/MIXED

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ rclone lsl S3_WEBDAV_TJA:CONTENT/MIXED | grep TESTFILE

29 2026-02-03 10:21:56.000000000 TESTFILE

* TESTFILE: listingTransferred: 0 B / 0 B, -, 0 B/s, ETA -

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ ls TESTFILE

-rw-r--r-- 1 tja staff 29 Feb 3 10:21 TESTFILE

So, the remote got the local mod time!

15

I then gave new content to the testfile, but set it's local mod time to an older date, from November 2025 and uploaded again:

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ date > TESTFILE

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ touch -r /etc/passwd TESTFILE

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ ls TESTFILE

-rw-r--r-- 1 tja staff 29 Nov 22 14:49 TESTFILE

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ rclone sync /Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED S3_WEBDAV_TJA:CONTENT/MIXED

<...>

tja@studio:/Volumes/WDBLACK/HETZNER/STORAGE_SHARE/CONTENT/MIXED$ rclone lsl S3_WEBDAV_TJA:CONTENT/MIXED | grep TESTFILE

29 2025-11-22 14:49:28.000000000 TESTFILE

* TESTFILE: listingTransferred: 0 B / 0 B, -, 0 B/s, ETA -

All seems to work and would suspect Google Drive to behave the same

16

hi, i posted an example up above showing gdrive working as expected.

17

The one short sentence is that my local directory says modification time 2022 and my remote directory says modification time 2026. The files themselves have the desired modification times.

I ended up using:

PS C:\rclone-v1.72> $RCLONE_NO_UPDATE_MODTIME=false
PS C:\rclone-v1.72> $RCLONE_USE_SERVER_MODTIME=false
PS C:\rclone-v1.72> .\rclone copy -v --drive-chunk-size 128M --transfers 12 --bwlimit 111M --drive-stop-on-upload-limit "localfiles\folder" "remote:folder"

This somehow did not work.

I think I might see the issue. @TJA has a solution that works for files. But yes. I already know how to do this for files. That is easy. My concern is changing the modification times for the directories themselves.

@asdffdsa is showing a NEWER time replacing an OLDER time which is a default behavior. But forcing an OLDER local time to replace a NEWER remote time is what I was trying to do, and failing miserably so far.

EDIT: note I wrote nonsense here and deleted it and now I have a cleaner post.

EDIT2: The -v output does indicate that the environmental variables are found to be meaning to rclone, but my guess is that they only apply to files and not directories, and as such my goal might actually just be impossible.

18

Yes, but you didn't do the test with locally older timestamp and upload of that.

19

I cannot tell you if this is the right way to set environment variables on you OS!

Better check out the command line options instead of the variables!

I saw also –refresh-times which should help to update remote files without re-upload!

It’s variable is probably RCLONE_REFRESH-TIMES=true

Really, read the documentation - all seems to work!

20

PS C:\rclone-v1.72> .\rclone copy -v --drive-chunk-size 128M --transfers 12 --bwlimit 111M --drive-stop-on-upload-limit "localfiles\folder" "remote:folder"

And your “localfiles\folder” really sits below your rclone installation in C:\rclone-v1.72?

So, in C:\rclone-v1.72\localfiles\folder ???

Otherwise your syntax may be wrong!