You should also update to the latest version so we can test on the same version.
Here's the log:
http://paste.ubuntu.com/p/9Q8FvGTnb8/
I will update to the same version, test the same mount command, then if it persists, remove the timeouts and try again
I'd be curious on the new version.
I can see the rename in the log and that looks right as well pointing to the new location.
I can't reproduce the nesting issue on rclone v1.50.2 on my setup anyway.
Interesting results:
abhishek@dragon:/mnt/gdrive/TV Shows/test/test2$ ls -al
total 0
abhishek@dragon:/mnt/gdrive/TV Shows/test/test2$ less test3.txt
1234512345
So it's the directory listings missing, but the file is showing up.
abhishek@dragon:/mnt/gdrive/TV Shows/test/test2$ rclone version
rclone v1.50.2
- os/arch: linux/amd64
- go version: go1.13.4
And, as expected, removing the dir-cache-time and attr-timeout solves it
The default for dir-cache-time is 5 minutes, did you wait 5 minutes or did it just work?
I'd think it's probably the attr timeout.
It just worked.
Yeah, I can recreate it with attr-timeout set to something larger than a few minutes.
Very easy:
2019/12/04 20:21:39 DEBUG : test/: >Lookup: node=<nil>, err=no such file or directory
2019/12/04 20:21:39 DEBUG : test/: Lookup: name="test2"
2019/12/04 20:21:39 DEBUG : test/: >Lookup: node=<nil>, err=no such file or directory
2019/12/04 20:21:39 DEBUG : /: Rename: oldName="test2", newName="test2", newDir=test/
2019/12/04 20:21:40 DEBUG : test2: Updating dir with test/test2 0xc0004418c0
2019/12/04 20:21:40 DEBUG : test2/test3/test4: forgetting directory cache
2019/12/04 20:21:40 DEBUG : test2/test3: forgetting directory cache
2019/12/04 20:21:40 DEBUG : test2: forgetting directory cache
2019/12/04 20:21:40 DEBUG : /: >Rename: err=<nil>
2019/12/04 20:21:43 DEBUG : /: Attr:
2019/12/04 20:21:43 DEBUG : /: >Attr: attr=valid=100h0m0s ino=0 size=0 mode=drwxrwxr-x, err=<nil>
2019/12/04 20:21:43 DEBUG : test/: Attr:
2019/12/04 20:21:43 DEBUG : test/: >Attr: attr=valid=100h0m0s ino=0 size=0 mode=drwxrwxr-x, err=<nil>
2019/12/04 20:21:43 DEBUG : test/: ReadDirAll:
2019/12/04 20:21:43 DEBUG : test/: >ReadDirAll: item=1, err=<nil>
2019/12/04 20:21:43 DEBUG : test/test2/: Attr:
2019/12/04 20:21:43 DEBUG : test/test2/: >Attr: attr=valid=100h0m0s ino=0 size=0 mode=drwxrwxr-x, err=<nil>
2019/12/04 20:21:44 DEBUG : test/: Attr:
2019/12/04 20:21:44 DEBUG : test/: >Attr: attr=valid=100h0m0s ino=0 size=0 mode=drwxrwxr-x, err=<nil>
2019/12/04 20:21:45 DEBUG : test/test2/: ReadDirAll:
2019/12/04 20:21:45 DEBUG : test/test2/: >ReadDirAll: item=1, err=<nil>
2019/12/04 20:21:46 DEBUG : test/test2/: Attr:
2019/12/04 20:21:46 DEBUG : test/test2/: >Attr: attr=valid=100h0m0s ino=0 size=0 mode=drwxrwxr-x, err=<nil>
2019/12/04 20:21:46 DEBUG : test2/test3/: ReadDirAll:
2019/12/04 20:21:46 DEBUG : test2/test3/: >ReadDirAll: item=0, err=<nil>
2019/12/04 20:21:48 DEBUG : test2/test3/: Attr:
2019/12/04 20:21:48 DEBUG : test2/test3/: >Attr: attr=valid=100h0m0s ino=0 size=0 mode=drwxrwxr-x, err=<nil>
2019/12/04 20:21:48 DEBUG : test2/test3/: ReadDirAll:
2019/12/04 20:21:48 DEBUG : test2/test3/: >ReadDirAll: item=0, err=<nil>
I basically just made a test and test2 dir, nested test3/test4 and put a file in all the way down. Moved it and I can see the directory but the file isn't there.
@ncw - seems to be a bug related to attr timeout.
What value would you recommend for this?
I don't think there is an issue with the value. I use 1 year on both - effectively disabling them an relying on polling for my updates.
If Animosity believes it may be a genuine bug that is causing the changes to not register then I would just wait for NCW's response (main author) because it might not be a user-error at all.
I managed to replicate that too.
What --attr-timeout does is sets the valid until data on info sent by rclone to the kernel - you can see that there
rclone does nothing with that value itself, it just passes it to the kernel.
You can see here fuse trying to list the directory and the fact that it is empty item=0
So what I think is happening is that somewhere there is a reference to the old directory with the incorrect path value it in.
I'm not sure where this is coming from - it must be cached by the go fuse layer I think.
Things I've noted
- this manifests with the local backend too so it isn't a drive problem
- I can't reproduce this with
cmount
I think this must be a bazil/fuse problem. I don't know if it is a bug for not, I suspect that I'm not invalidating the directory entry when I should.
The problem is caused by the directory node caching the full path in it and when it is pulled from the cache it has the old path in which is empty.
Workaround - don't use --attr-timeout - it shouldn't be necessary - it doesn't affect how much caching rclone does at all.
What I could do is stop the directory caching the path - that would fix the problem but seems like an unecessary work-around...
It looks like getting bazil/fuse to invalidate the directories might be hard: https://github.com/bazil/fuse/issues/111#issuecomment-140440227
It looks like I'd need to invalidate the directory and all of its children on a rename or implement the relative path scheme
Here is how I've been replicating the problem
echo "hello" | rclone rcat /mnt/tmp/test2/test3/test4/hello.txt
ls -l /mnt/tmp/test2/test3/test4/hello.txt
mv /mnt/tmp/test2 /mnt/tmp/test2a
ls -l /mnt/tmp/test2a/test3/test4/hello.txt
# file missing!
with
rclone -vv mount /tmp/mount /mnt/tmp/ --rc --attr-timeout 1000h
This was an interesting one. I have not been using attr timeout in my mounts for some time as I was always a bit concerned of something sticking around.
The work around for now seems simple enough.
It is probably worth fixing this since some --attr-timeout is needed otherwise fuse goes mad requesting everything all the time but obviously too much is harmful! Hence the default of 1s.
@Animosity022 I was planning on a setup similar to yours, but on github I see you're using attr-timeout there. Is that different from what you're using in practice, since you haven't seen the issue?
I sometimes forget to make a push up after removing something so I fixed it as I took attr-timeout out. Thanks for catching that for me.
No worries, thanks for the clarification!