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
21

i do not think that is valid, that does nothing?
perhaps it should beRCLONE_REFRESH_TIMES=true

true, but i had tested that but did not post it.

is this what you mean?

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

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

rclone copy d:\zork gdrive:zork  -v
INFO  : dir: Set directory modification time (using SetModTime)

rclone lsd gdrive:zork  -v
           0 2024-02-02 16:54:21        -1 dir
22

no localfiles\folder was slang. It’s actually a specific path on the D drive. The C drive is my OS drive and the D drive is my everything else drive essentially.

I did test with locally older directories, I just didn’t create or modify the test subject. The test subject is just correctly old, whereas the remote has a brand new modification time.

24

This is exactly what I want, although your example doesn’t match my experiences.

I run this….. in rclone-v1.72

rclone copy -v "localpath\folder\subfolder" "remote:\folder\subfolder"

rclone lsd -v "remote:\folder"

Then the result is that the date for “subfolder” on the remote is in 2026 and the date for “subfolder” locally is 2021.

In other words, your example I don’t see how the lsd returns anything at all?

rclone lsd -v "remote:\folder\subfolder"

has an output of nothing at all, and this appears to be the case with your zork example, hmm.

EDIT: in your zork examples you appear capable of making the remote date update to match your source local date, but…. I keep running the command in any which way i can think of and I don’t obtain the same results as you do apparently, hmm.

EDIT2: This time it just magically worked. Hmm. Your example doesn’t seem to work, but with another example it appears that it did work. As far as I can tell it only works to fix things like in your zork example if I am copy’ing a subfolder that contains other subfolders. Otherwise if my chosen test case is a subfolder with files in it and no more layers of subfolders it doesn’t work…. This makes no sense I feel like I must be doing something wrong on my end.

EDIT3: So, your zork example does not work for me, but this does:

if subfolder in this case contains a bunch more subsubfolders

rclone copy -v "localpath\folder\subfolder" "remote:\folder\subfolder"

then

rclone lsd -v "remote:\folder\subfolder"

Will correctly show I have now set all the dates to my local dates.

But it appears to fail if “\folder\subfolder” contains nothing but files.

EDIT4: My only conclusion is that the behavior is inconsistent, depending on the nature of subfolders that do not contains more folders. Which might be a bug? Or more likely this is a quirk of running rclone copy commands where you know you’ll be seeing “2026/02/03 17:23:16 INFO : There was nothing to transfer” and maybe those usage cases aren’t important enough for inconsistent behavior to count as a bug.

TLDR: The newest zork example is what I want, but I do not find the behavior consistently reliable outside of very specific scenarios. To clarify. It ALWAYS works reliably and consistently for files, but the behavior of directories is frustrating.

25

You are a hard case.

lsd only shows directories.

RTFM!

And mod times of directories are totally unimportant!

The mod time of a directory changes as soon as you add, remove or change something in it, even temporarily when using an editor in that directory. Don’t care about this, really.

You should care about mod times of files, those are important!

Check with lsl instead of lsd!

26

You’re correct. I am obsessing over a detail that is not very important. That is why no one understood what I was asking. Most people just assumed I meant files and I meant lsl.

It just annoys me that directory modification times ALMOST work exactly like I want them to, but just ever so slightly don’t.

In other words, that explains our misunderstanding. Everything you said was true for files, but I already had that working fine.

Sorry for having wasted your time.

27

I tested this now for remote directories, and it seems that this does not work - at least not for WebDAV remotes!

The remote directory mod time will be that of the upload.

Google Drive may behave differently here!

And maybe using RCLONE_METADATA=true can help here!

Probably only for new uploads!

Finally, “rclone touch” may help!

Manual work …

28

that is documented at the man page!

you wrote all that to @left1000 but the same applies to you!

29

I did read, I just wanted to test.

No need to reply to me!

Go ahead…

30

Manual work is fine. this issue only arises for people updating to a new version of rclone and not knowing to use --no-update-dir-modtime

In other words only a few folders of mine have the issue.

Of course the problem with rclone touch is that it appears to only effect files not directories. Oh well.

Like I said in my last post, I am beginning to think this issue just cannot be solved, and is far too minor and niche for rclone to need to be updated to allow me to do what I wish here.

Thanks for trying though.

EDIT: There also appears to be this related issue already created that is related. Sync directory modification time and metadata on the root of the sync ¡ Issue #7652 ¡ rclone/rclone ¡ GitHub In theory if that issue ever gets solved then my issue in this forum thread might also be solved. But it is again so low priority it may never happen and that is fine.