Windows: Maximum name path length (works fine)

[Owyn]

Was testing filename\path length limit, cuz I had some number of filenames exceeding it even disregarding folder names

results:

• when trying to copy a file with a name longer than 143 symbols it properly gives an error about name being too long (cuz resulting encrypted filename would be bigger than 255) - expected behavior
• when trying to copy a file with a name under 143 symbols into a subfolder which makes total sum of paths longer than 143 symbols it doesn't give an error, file stays accessible on the mounted point but becomes partially inaccessible in the standart windows explorer on the source mount point with encrypted files cuz its file path now exceeds windows path_max of 260 symbols - not an issue as it is

opening\working with folders on mountdir works fine, except for some minor issues: 1) renaming folders, trying to rename a folder which is a part of the issue results in an error "access denied" (only with disabled long paths windows settings) - with it enabled works fine 2) filename length check doesn't account for double-byte+ (probably) characters like russian language or just some symbols like dash— and therefore doesn't calculate limit correctly for a proper error display, instead it gives "can not find this element" in the explorer and "syntax error" in the console: steps to reproduce:

• create a 143 symbols filename
• replace one symbol with a dash —
• try to save the filename - get "element not found" error

  [Error] [0000000000001890] [2019-09-12 12:02:17.704446400 UTC]    rename from=/241291-2200x1200-original-nanfe-long+hair-single-looking+at+viewer-highres2 IT WORKS/241291-2200x1200-original-nanfe-long+hair-single-looking+at+viewer-highres 1 12334534534534 34543 45645654645 45645645645645 56666666666122.jpg to=/241291-2200x1200-original-nanfe-long+hair-single-looking+at+viewer-highres2 IT WORKS/241291-2200x1200-original-nanfe-long+hair-single-looking+at+viewer-highres — 12334534534534 34543 45645654645 45645645645645 56666666666122.jpg encounters exception class securefs::WindowsException (code=2): error 123 Syntax error in file name, or folder name or tome name. (MoveFileExW(path1=\\?\V:\SF\TCEH9K872798Z2SY3HAR5QXPN3UX3DX8EKNP4SSAXWE286FZ2R729A6U5ESSRME2RXBSFT2UMTZZIPM93M468KVZR6D5B8SMHWC5ZAAZNF8IMDDQUPFXWAJ6ESWFC2VEHWFHYT375FJNYX74DRPCVGGP382UR6NH\37STDPC6FHD7YG2F84MY77HDSM49XBWVJDRDSAYCMMK5F2NDIES22X6ZAIZKJYK7BKJBVTHI8DRXQH5BCCYHGQZZPZHPF5N8EMTR9ZG5CMI5RVXPWRUUQRV77N96P8GNT2AF5PB5RZIFPSEUVJI7IRHSNRU2NN4P4IHGIS48D4ES56JHB9ZC87SD43MWYD42FQVACWW8CJBPPQ6ZAY78EBN633AUXREGPVB3ZXXISH7GP8FXQ463S4CCK96JVU2, path2=\\?\V:\SF\TCEH9K872798Z2SY3HAR5QXPN3UX3DX8EKNP4SSAXWE286FZ2R729A6U5ESSRME2RXBSFT2UMTZZIPM93M468KVZR6D5B8SMHWC5ZAAZNF8IMDDQUPFXWAJ6ESWFC2VEHWFHYT375FJNYX74DRPCVGGP382UR6NH\UE7CZG63HPUAYERJ2S68HT5PB2STCYBCQIPEW8IHT84YBJYE9QISCAWUBH53US6QEGCQS2338QSE229PVHDXYCYHIVP2DX7CG23Q6N2CJ7JSUE9PRCTENMMBCRGAXJ9QMPU9M4DS9ZHV23C98GSWAI9XP4MTFJWVXWIHBYHFTUTTFZTUARK29W3YTY2HWD6SFRN7EVE6IEZRXJNH2B49CKJYGFAQZBI7C5FXFFBAHF6YWBGUHB272EDY6SSIMNXDFE))

[Error] [0000000000000904] [2019-09-11 18:00:43.867028000 UTC]    rename from=/241291-2200x1200-original-nanfe-long+hair-single-looking+at+viewer-highres to=/very long folder name just to test things out and see how it goes encounters exception class securefs::WindowsException (code=13): error 5 Access denied. (MoveFileExW(path1=\\?\V:\SF\V92D83W6G746NF8DPDE8UUA95XXV7HH4DIHT4PDU8EBQBM3YQZS2FKPVAHSPYRYUWV8YD3R7XEQFJ5HMUQ26FEWRJ5G8B54M7YWMYJSDFAN7S4TZ83WIK7D79MM96ZBRNIRENRVNJ6UG5PQ5, path2=\\?\V:\SF\WIYANA4BBFY8VTTDVYRE8IZX6C59RFJHESXGHI6D296KMU8EJHY6DQE4UFVDQP8V8MDJPVJXQCNMRH5ICRX24PZAQMWSSYJVNFBHE9HXFXWRUUDFFWU6559ZG84JNWG5NW))

Windows 10 b1903 SFS 0.8.3 WinFsp 2019.3 B2

in 2016 Microsoft officially made an option to disable the path limit of 260 https://mspoweruser.com/ntfs-260-character-windows-10/ enabling it for following functions:

CreateDirectoryW, CreateDirectoryExW, GetCurrentDirectoryW, RemoveDirectoryW, SetCurrentDirectoryW.

CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.

thought it was long ago (since Win2k) possible to work with long file paths on NTFS using \\?\ prefix, but now in 2019 even without it and with just settings it would all work fine if user enabled long names in windows 10 settings

maybe it's a good idea to add this info to the README about enabling long path names in all modern versions of windows and say that securefs officially supports longs path now (all seem to work fine)

[netheril96]

Is the actual data on a NTFS volume?

V: doesn't look like a label usually assigned to a disk partition.

[Owyn]

You can assign any drive letter to any partition on windows (including system one) It's NTFS

[netheril96]

securefs never needs the long path option, because it always interact with Windows API in the long form. From the log message you can see that the actual filename Windows see is like

\\?\V:\SF\WIYANA4BBFY8VTTDVYRE8IZX6C59RFJHESXGHI6D296KMU8EJHY6DQE4UFVDQP8V8MDJPVJXQCNMRH5ICRX24PZAQMWSSYJVNFBHE9HXFXWRUUDFFWU6559ZG84JNWG5NW

I can't reproduce your problem on my machine, with the same filenames. Could you give more details?

[Owyn]

WIYANA4BBFY8VTTDVY access denied happened only before I enabled long paths option for windows, now it doesn't

it's the error for renaming folders, trying to rename a folder which is a part of the issue results in an error "access denied" (only with disabled long paths windows settings) - with it enabled works fine

but you needed to also have a file with long filename inside that folder you are renaming to get this error access denied

[netheril96]

The error is with Windows Explorer not properly supporting long paths, not securefs.