Directory modification time not updated unless directory cache manually flushed in rclone mount

Suspected Bug
1

What is the problem you are having with rclone?

Hi,
I use rclone mount with crypt to encrypt a local folder and I ran into a problem, because the modification time of directories in the mount are not updated.

I will try to explain with a simple example, but first the requested information:

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

root@rp:~# rclone version
rclone v1.62.2
- os/version: ubuntu 22.04 (64 bit)
- os/kernel: 5.15.0-73-generic (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)

local crypt mount (also tried webdav)

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone mount testcrypt: /root/decrypted -vv --dir-cache-time 1m

The rclone config contents with secrets removed.

[testcrypt]
type = crypt
remote = /root/encrypted
password = REDACTED
password2 = REDACTED

A log from the command with the -vv flag

Example:

First, create a directory "testdir" inside the mount, then two minutes later create a file "testfile.txt" inside the new directory. Note the timestamps.

root@rp:~# mkdir decrypted/testdir
root@rp:~# ls -l decrypted/
total 0
drwxr-xr-x 1 root root 0 Jun 13 17:20 testdir
root@rp:~# touch decrypted/testdir/testfile.txt
root@rp:~# ls -l decrypted/testdir/
total 0
-rw-r--r-- 1 root root 0 Jun 13 17:22 testfile.txt

Wait for two minutes or more. By now, the directory cache should have been flushed (note --dir-cache-time 1m) and I would expect the modifcation timestamps of both, "decrypted" and "decrypted/testdir" to reflect the creation times of the "testdir" and "testfile.txt", respectively.

root@rp:~# ls -l decrypted/
total 0
drwxr-xr-x 1 root root 0 Jun 13 17:20 testdir
root@rp:~# ls -lr
total 12
drwxr-xr-x 3 root root 4096 Jun 13 17:20 encrypted
drwxr-xr-x 1 root root    0 Jun 13 17:18 decrypted

Note how the timestamps in the remote folder "encrypted" have been properly updated, but not in the rclone mount.

We can also show that the mtime is not updated when the remote changes, by deleting the encrypted testfile.txt:

root@rp:~# rm encrypted/ijjmpu1lf1ueb3giclqcor5hns/68cn1qmmvokgrues4sfqok3b38

Wait again for at least one minute to verify that the timestamps have not updated in the mount:

root@rp:~# ls -l encrypted/
total 4
drwxr-xr-x 2 root root 4096 Jun 13 17:23 ijjmpu1lf1ueb3giclqcor5hns
root@rp:~# ls -l decrypted/
total 0
drwxr-xr-x 1 root root 0 Jun 13 17:20 testdir

Manually flush the directory cache by sending SIGHUB to the rclone process. Discover that the timestamps have now been correctly updated.

root@rp:~# kill -SIGHUP $(pidof rclone)
root@rp:~# ls -l decrypted
total 0
drwxr-xr-x 1 root root 0 Jun 13 17:23 testdir
2

hello and welcome to the forum,

as far as i know, rclone cannot update modtime for directories
https://github.com/rclone/rclone/issues/1669

1 Like
3

Oh that explains a lot. Thank you very much for the quick answer.

I don't know how I missed this issue, I was googling quite a lot. Maybe this piece of information could be added to the documentation for rclone mount?

4

Rclone doesn't set the modification time of directories if you modify files within the directory it relies on whatever the cloud provider does.

So this behavior is probably to be expected with the exception of it not updating after the directory cache has expired.

When the directory cache has expired we don't actually ditch it from memory, we keep it and when we re-list the directory we swap in changed objects. We don't however swap in a new directory object as you need to list the parent directory to get this.

We probably shouldn't be doing this swap around because

  1. It uses memory for the expired items
  2. Problems like this one

Ideally we'd expire each directory out of the directory cache and remove its objects.

There was a patch to rclone to do this but it isn't ready to merge yet.

1 Like
5

Thank you for clarifying!

6

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