How does --max-age behave when combined with --no-modtime (recipe for disaster)

Help and Support
1

What is the problem you are having with rclone?

None! I did spot something that confused me when I erroneously used --max-age & --no-modtime together like:

rclone mount --allow-other ... --no-modtime --max-age 269d ...

Run the command 'rclone version' and share the full output of the command.

rclone v1.62.2
- os/version: debian 10.13 (64 bit)
- os/kernel: 4.19.0-23-amd64 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.20.2
- go/linking: static
- go/tags: none

Which cloud storage system are you using? (eg Google Drive)

Google Drive

A log from the command with the -vv flag

2023/04/27 17:56:34 DEBUG : --max-age 8.966666666666667M to 2022-08-01 17:56:34.510375486 +0200 CEST m=-23241599.947463579
  • anyone can explain how does it end up with 8.966666666666667M ?

What I found a bit interesting is that while I did get files way before Aug 2022, there was some filtering taking place as the mount did not contain all the files of the remote, in fact it contained a relatively small part of it around the same size I was expecting through the proper use of --max-age which is why it took me a bit to figure it out.

Which brings us to how did those two flags work together?

Edited to add information from the template I had removed
I kept the command & config part out as I think are unrelated, feel free to correct me!

2

Without knowing the details in the template, as we don't know what version you are running and the fact that there are many changes that happen each release, it's tough to guess.

That's why we put so much effort in the template and ask folks actually use it.

3

Oh, I had added most info in the template but removed some as I re-structured the post. Seems I removed almost everything :slight_smile:

Editing original post.

4

I 'll take an attempt to answer it myself. The filtering did work properly and that's why I saw it was the ~same size.
The reason behind the "older" files is simply --no-modtime, the files got the modtime of the directory they are in. In one case the dir had a modtime from 2020 while the files in reality are from 2023.

Next step on this trip of self discovery, how is the mod time set on dirs when --no-modtime is set?
Also would using --use-server-modtime have a different effect?

5

I think it is just the current time.

This will use the upload time of the object on s3/gcs. On google drive it will have no effect.

6

The dir had a modtime from 2020-01-20. This is a directory in the remote, not the mount path:

total 28625028
drwxr-xr-x 1 rclone rclone          0 Jan 20  2020  .    <-- dir from remote
drwxr-xr-x 1 rclone rclone          0 Apr 28 00:32  ..   <-- mount path
-rw-r--r-- 1 rclone rclone  736172122 Jan 11 21:17       <-- file

Thanks, was wondering if and what effect it will have on google drive since it is a provider supporting mod time.

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.