Kopia is a great backup program. Thank you for your hard work.
I found a curious bug in the mount command. Mounting respiratory works fine, when called within Kopia UI. There’s example of “offending” directory, report its content (note, there are 6 files): [don’t mind the revere of “/”, that because of 2 “link” limit for the new posters]
But when using mount command, files are not displayed:
Directory of “z:\xxx@xxx\C_Users_xxxxx_AppData_Roaming_Thunderbird\20220414-141421\Profiles\xxxx.xxx\ImapMail\imap.gmail.com[Gmail].sbd\All Mail\cur”
2022.04.13 16:17 . File Not Found
Curiously, while accessing that directory, debug command (mount --trace-fs), says:
DEBUG kopia/cli
(Readdir) z:\xxx@txxx\C_Users_xxxx_AppData_Roaming_Thunderbird\20220414-141421\Profiles\xxxx.xxxx\ImapMail\imap.gmail.com[Gmail].sbd\All Mail\cur took 0s and returned 6 items
So, they are “there” but they are not. This is only affected by using “mount” command in the cmd environment (win10). And, yes, I checked already “FileAttributesLimitInBytes” entry in the webclinet registry section, same result. I spotted error/bug by pure chance in the only one respiratory (thunderbird backup) so far, but that bug occurs in the other directories (they are empty) of that respiratory. Btw, shortening backup path doesn’t work either (e.g: backup only “ImapMail” directory instead of whole “profile”, same result.
This text will be blurred
When you run kopia backup, does thunderbird/outlook or any other email client is working/opened?
It looks to me as file simply locked by either email client or operation system(that locks files when antivirus scanning them constantly)
Directory of [z:\xxx@xx\C_Users_xxxx_AppData_Roaming_Thunderbird\20220415-135505\Profiles\xxxx.MyMail\ImapMail\imap.gmail.com[Gmail].sbd\All]
2022.04.15 11:01 . File Not Found
Debug log:
2022-04-15T15:01:52.872782Z DEBUG kopia/cli Readdir(./xxx@xxx/C_Users_xxxs_AppData_Roaming_Thunderbird/20220415-135505/Profiles/xxxx.MyMail/ImapMail/imap.gmail.com/[Gmail].sbd/All Mail/cur) took 0s and returned 8 items
Hm. Yes, they are there (kopia list -l -r to scan subdirectories of that object id). No problem here.
They’re not available in the cmd (file not found) or windows file explorer (just empty directory). Debug massage shows - (DEBUG kopia/cli Readdir(…) took 0s and returned x items) - as normal.
Long filename together with long path exceeds 220 characters limit of webdav (webclient) server. According to Internet, 220 is a limit. Mount via KopiaUI just shortens path (hops user name, archive name and date of snapshot), so problem in this particular case, do not occur. As I understand, nothing can be done at the Kopia side (maybe some sort of warring?) One must by careful when planning backup archive.
Yes, it operation system restriction, so no, nothing can be done at kopia’s level if it doesn’t use privileged WinAPI (and it shouldn’t), but what you can do, is to fire up kopia’s “action” and call some script where you run 7zip that in turn archive those directories in question since 7zip can go beyond of 220 limit, then just ignore those super long dirs
UNC path as mount point? Ok, I checked your idea in the Powershell (cmd doesn’t use USN paths), and…
Microsoft.PowerShell.Core\FileSystem::\?\z:\xxx@xxx\C_Users_xxxxx_AppData_Roaming_Thunderbird\20220416-143516\Profiles\xxx.MyMail\ImapMail\imap.gmail.com[Gmail].sbd\All Mail\cur> dir dir : The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
But other way to bypass this, is to use a different Webdav client - for example - webdav plugin for Total Commander doesn’t have any problem displaying long paths (also with accessing files bigger than 2GiB).