I didn’t say I had one. I did ask you to test to see if your case fails like mine, but my guess is yes.
To be specific, you could (as root) test if stat /home/andrei/test/source/yandex-disk fails.
You probably established that with ls -ldn though, although I’m less confident how that queries.
It starts with a FUSE bug, IMO, breaking normal Linux behavior, although one can argue about it.
It definitely gives an access error for an unlisted case, but that might just be how things go now…
Changing Duplicati (if it can be done safely, and that’s a developer call, not mine) would be good.
Maybe testing for a block special file (such as disk) is done first to try to reduce damage risk later.
Because the forum is not a bug tracker, could you see if the other topic filed this issue? If not, file.
Documented stat behavior (see lstat man page, which seems to hold at least locally) is generous.
These functions return information about a file. No permissions are required on the file itself, but-in the case of stat() and lstat() - execute (search) permission is required on all of the directories in path that lead to the file.
$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
$ ls -ldn mail.ru
d--------- 2 1000 1000 4096 Sep 7 15:00 mail.ru
$ ls -ln mail.ru
ls: cannot open directory 'mail.ru': Permission denied
$
But under FUSE, permissions apparently ARE required on the file itself, adding a new way to error.
Regardless, it would be good for Duplicati to allow the user to manually exclude the problem folder.