Hello,
I just started using restic (version 0.9.6) on Windows 10.
During my initial backup with restic -r D:/ --verbose backup C:/Users/myusername/work
and during any further backups with the same command, I get the following messages:
scan: CreateFile \\?\\con: The parameter is incorrect.
scan: CreateFile \\?\\con: The parameter is incorrect.
scan: CreateFile \\?\\con: The parameter is incorrect.
scan: CreateFile \\?\\con: The parameter is incorrect.
and
error: CreateFile \\?\\con: The parameter is incorrect.
error: CreateFile \\?\\con: The parameter is incorrect.
error: CreateFile \\?\\con: The parameter is incorrect.
error: CreateFile \\?\\con: The parameter is incorrect.
Otherwise, the backup works fine.
Speculation: It may be that I have 4 files with “strange” filenames, if I interpret \?\con as escape sequences. But how do I get the full path of theses files? So I can rename the files.
D:\ is a local USB harddrive with NTFS filesystem. But many of the files
in C:/Users/myusername/work are from “linux” by syncthing a linux and a Windows machine.
Does adding -v or -vv to the backup run command (e.g. before the -r) yield any relevant information about the files? Can you tell us which four files you suspect, what are their exact filenames?
I redirected the output of a powershell script containing the above mentioned command line to a log-file.
The full path of the files processed “before and after” this error: message contain no special character
and the full path + filename is about 150 character long. I cannot post path/filenames as it contains the name of a real person. But the path/filenames are “pure ASCII” containing [a-z,A-Z,0-9,_,-,.]. (No comma in the path).
So, maybe my first speculation of a “strange” filename is not correct.
Unfortunately, I have about 500k files in the backup path, the log-file, with -vv, is about 200MB.
The scan: message in the log-file only gives [2Kscan: CreateFile \\?\\con: The parameter is incorrect.
Well, the error gets triggered in the powershell script restic.ps1
Added later: As I redirected stdout and stderr with 2>&1 > log-file.txt it could be that the output order in the log-file is kind of scrambled. I mean, I don’t know if restic/powershell does a buffer flush after each print statement.
Thank you Michael.
I tracked it down backing up different subfolders and check if error messages pop up.
My backup folder contained 4 times a file named “con.m” (without the quotes). That causes the scan and error messages of restic.
A small matlab file. I couldn’t rename that file with the Windows File Explorer; right click -> Rename -> Error: Invalid file handle. I renamed the 4 files on the linux machine and used syncthing (syncthing.net) to “rename” them in Windows. And the scan and error messages are now gone.
I knew, that con, prn, … are not valid filenames. But con.m … didn’t expect that.
Well, I would find a feature in restic, that prints me the whole path of the processed file in the case of an error or scan message, very helpful. Maybe an option --verbose 3 . Sometimes I get files from colleagues using OSX or Linux.
And if I sync my linux machine with Windows this leads sometimes to path-/filename clashes. Syncthing tells me that usually, but in this particular case, con.m, it was just transfering the file and I could open that file with a text editor. Ok, you could argue that this is a syncthing problem. But I could imagine in the case I have a bad sector (read error) on a harddrive, restic could tell me what file caused an error. Just saying, not really urgent … more something for the wishlist.
Restic really tried to open \\?\con and that fails, so restic is already reporting which file failed to open. The problem is that the filepath is totally broken. When restic tries to normalize e.g. C:\restic\con.example then the computation of the absolute path yields con (I’m looking at you GetFullPathName). As restic supports paths longer than 256 characters it has to prepend \\?\ which gives us \\?\con. (btw, the correct and non-ambiguous filename for the console device would be \\.\con) I’m not sure where one of the backslashes disappeared in the error message.
The Definitive Guide on Win32 to NT Path Conversion shows that prepending \\?\ to an already absolute path seems to get rid of most weird behavior during filepath normalization. I’m just not sure whether the Go functions to process filenames can handle this. That is it should be possible to add support for con.m and other reserved filenames to restic, it will just take some time to work out the right magic incantation.
Thank you again Michael!
Ok, I had this naive idea that an absolute path is just a “long” string, which one could print. Thanks to you I learned that in Windows this seems to be more complicated to keep old DOS paths styles alive and that may lead to a broken path.
May I add: I was using in Windows 10 the “Back up using File History” from the “Settings Menu” to “backup”. Sorry. And several weeks ago this stopped working. It didn’t finish anymore an even manually started backup session. But there was no error message. I started looking around and found restic.Now reflecting on that, around the time “Back up using File History” stopped working a colleague gave me the file con.m from OS X.
