The leading and trailing ’ is not part of the filename, I used it to emphasize that the second file in the listing has a trailing blank in the filename. The others have a trailing dot. The error is the same for all three files: “File not found”.
I first suspected a file name length problem, but all three files are in directories with even longer filenames, which work fine. Also, I tested a copy of the containing directories with robocopy, no problems there either.
Funky characters? You can test that theory by making a copy of the file(s), verify that the problem reproduces correctly with those copies, then getting rid of one funky character at a time, reproducing the problem in between.
I don’t think its funky characters, but really the lack of extension for some reason: I renamed all three files (after investigating what format they actually were) to have the extension .pdf without touching the rest of the name and now the error does not happen any more. Some weirdness with reading the filenames in a directory perhaps?
OK, a bit more testing to get to the bottom of this: I created a directory “aaa” right underneath the top level directory that is the source of the backup to eliminate any file name length problems and inside that directory three files with random data named
‘xxx’
‘yyy.’
'zzz ’
Again, the leading and trailing ’ is not part of the name. ‘xxx’ works, the other two cause a ‘file not found error’. The error message actually says ‘yyy: file not found’ and ‘zzz: file not found’, omitting the trailing blank and dot both times. So maybe the system call used in restic to read directory contents does not do the “right thing” by omitting those characters?
“Problem” is that these are valid NTFS names, but… not valid Windows names:
Source:
Quote:
Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. However, it is acceptable to specify a period as the first character of a name. For example, “.temp”.
If you are using Windows I think my advice would be to make sure that you do not try using something what is not officially supported. Especially when it does not serve any purpose.
It is a bit lack of consistency from Microsoft end but it is not the worst what can be found in Windows:)
Dot or space at the end of a file can behave differently with different Microsoft tools. Explorer might not work but power shell can etc. Better to avoid such situations - as per Microsoft specification.
It is possible that some 3rd party tools work with such names - pure luck or carefully chosen API which bypass official restrictions. IMO it should not be restic goal to support it. In addition it can be ephemeral behaviour changing without any notice.
I DuckDuckWent a bit more on this problem and came up with these two links:
Apparently the Win32 file I/O API does some funky things to file names, for instance chopping off trailing spaces and dots. The MS link explicitly states to “Do not end a file or directory name with a space or a period.”. All of that file name parsing can apparently be suppressed by prepending "\?" to strings/filenames passed to the API. I don’t know if that is an option for restic though.
Victim of some parsing here as well. This is what the prefix should look like: “\\?\”
Also, thanks to kapitainsky for his comments, which overlapped with mine. If the prefix is not an option for restic, user education is probably the way.
Funky character == any character that is not allowed in a filename. That’s why I suggested you reproduce the problem and then remove character by character that is not 100% known to be valid. Windows is picky about its filenames, unfortunately. You get what you use
See my further tests and the post @kapitainsky. It is restrictions of the Win32 file I/O API which mangles filenames that end in blanks or single dots (but which are legal NTFS names). There is a possible workaround as well, but it is not clear, if it is something that restic can use.
