pkolaczk / fclones

Efficient Duplicate File Finder
MIT License
1.97k stars 75 forks source link

os error 123 in Windows 10 #17

Closed PeWu closed 4 years ago

PeWu commented 4 years ago

Running fclones * in Windows 10 results in an error (sorry for the error message in Polish ;-)

[2020-07-19 16:53:35.267] fclones.exe: error: Failed to stat C:\*: Nazwa pliku, nazwa katalogu lub składnia etykiety woluminu jest niepoprawna. (os error 123)
[2020-07-19 16:53:35.269] fclones.exe:  info: Scanned 0 file entries
[2020-07-19 16:53:35.270] fclones.exe:  info: Found 0 (0 B) files matching selection criteria                           
[2020-07-19 16:53:35.272] fclones.exe:  info: Found 0 (0 B) candidates after grouping by size                           
[2020-07-19 16:53:35.274] fclones.exe:  info: Found 0 (0 B) candidates after pruning hard-links                         
[2020-07-19 16:53:35.277] fclones.exe:  info: Found 0 (0 B) candidates after grouping by prefix                         
[2020-07-19 16:53:35.278] fclones.exe:  info: Found 0 (0 B) candidates after grouping by suffix                         
[2020-07-19 16:53:35.280] fclones.exe:  info: Found 0 (0 B) duplicate files

Running fclones . -R works properly and also running under WSL works properly.

pkolaczk commented 4 years ago

I'm afraid Windows default shell doesn't expand wildcards. https://superuser.com/questions/460598/is-there-any-way-to-get-the-windows-cmd-shell-to-expand-wildcard-paths

You can use a combination of -R and --paths ... or --names ... to perform globbing with the builtin glob/regex support.

PeWu commented 4 years ago

Could you fix the documentation and error message? The current error message is quite misleading.

pkolaczk commented 4 years ago

The error message is created from the template: Failed to stat <path>: <reason> The second part (reason) after the colon comes from the operating system. I can't fix it.

I can improve only the first part a bit. I guess "stat" is a Unix/Linux only thing. What about Failed to read metadata of <path>: <reason> ?

PeWu commented 4 years ago

I don't think changing wording would help much. I wouldn't have guessed that the program is trying to use '*' as a file name. And even if I realized what the program tried to do, I wouldn't know what to do about it.

You could do something like:

if path contains '*':
  log warning 'It looks like your shell does not support expanding wildcards. Try using --paths or --names. See https://git.io/JJCLH for more information.'
pkolaczk commented 4 years ago

I like your suggesion, although I can imagine the warning could be also wrong and misleading - there is no reliable way of determining if the given file system accepts (or any other character) as part of the path. E.g. on Linux is a perfectly valid character in a path. The tool does not know if the user wanted to treat as a wildcard, or maybe they wanted a literal .

I can also imagine the above code could raise the warning even under shells that do support wildcard expansion. E.g. this is a valid command under bash: fclones -R '*' (search all contents in the directory named * )

PeWu commented 4 years ago

Thanks :)