[Warning-Duplicati.Library.Main.Operation.Backup.FileEnumerationProcess-FileAccessError]

Support
41

Nice work troubleshooting!

Although I still can’t get the CIFS VFS: Send error in read = -4

For me this error is quite rare compared to the “Close unmatched open” one, which I agree always seems to be only on folders.

My test data set has about 25k files in it totally 9GB, so the files are pretty small on average. I think I’d get the “Send error in read” maybe half a dozen times during the first full backup. Pretty sure the “Send error in read” message was always tied to an actual file, not a folder.

What might be helpful is if we could come up with some very basic mono application that triggers this problem, then open an issue against the mono project. With their eyes on it maybe the devs could decide if it’s a mono bug or not.

42

Directory.GetFiles Method example is a bit less basic, but can trigger given the right signal environment.
The Mono log profiler (in mono-complete package and other spots) signals enough. I’m using its syntax:

$ mono --profile=log:help some.exe
...
sample[-real][=FREQ] enable/disable statistical sampling of threads
                     FREQ in Hz, 100 by default
                     the -real variant uses wall clock time instead of process time

mono --profile=log:sample=1000 Microsoft.GetFiles.exe /mnt/emptyfiles fails on Linux Mint 19.3 with kernel 5.4.0-62-generic, but works on Manjaro Linux with kernel 5.9.16-1-MANJARO, and works on openSUSE Tumbleweed with kernel 5.10.9-1-default. I’d guess the reason is they have a kernel patch:

[PATCH] cifs: allow syscalls to be restarted in __smb_send_rqst()

Let me the kernel decide to whether or not restart the syscalls when
there is a signal pending in __smb_send_rqst() by returing
-ERESTARTSYS. If it can’t, it will return -EINTR anyway.

I wasn’t (and still am not) sure how general a fix this is, but for whatever reason the getdents/getdents64 system calls underneath the readdir that I think mono is using are doing better. Some distro kernels may eventually catch up. The two distros I picked for their test are rolling releases known to stay quite current.

Linux 5.10-rc7 shows it going into Linus’ kernel candidate Dec 6, 2020.
Linux 5.9.14 shows it going into that kernel.org kernel on Dec 11, 2020.

For additional testing, I also used a C program to send signals, with directory readers written in C and go.
I’m not sure what go has internally, but in the C program I used SA_RESTART in sigaction, so in patch’s context, I tell the kernel to restart, and then the patch allows linux-cifs to ask the kernel, so it does restart.
Both of these programs failed on the older Linux Mint system, and worked on the two leading-edge ones.

Ubuntu 20.10 with kernel 5.8.0-41-generic fails. This might be a Jan 18, 2021 kernel, but I don’t know how hard Ubuntu works to keep their kernel up to date with the latest kernel patches. SUSE documents nicely.