Beta Testers needed for new file manager

Double posted by mistake

jimbo45 said:

Hi there

@CountMike
It in common with all the current Windows file managers only changes the GUI and not the underlying code so it doesn't make use of the ability to display long paths and file names as it uses / calls current "file explorer" type API's.

I agree TC is much better than file explorer -- however a lot of programs that allow you to browse to select a file are still using current API's so again no long file name display -- you still get the 8.3 format when a file name can't be displayed properly (too long).

For example these sorts of files only get displayed in 8.3 format in Windows

Attachment 250380


Windows needs to change the browse API's -- support for long file names is currently allowable in 1903/1909 builds but I haven't seen any programs yet that use it.

(Actually one exception -- if you use WSL2 then you can access these files properly from a NAS -- but that's using the WSL and not file explorer or its replacements such as TC).

(I'm not renaming zillions of music file that display perfectly OK on my NAS !!!!!! -- KODI also displays those on a FireTV -- Android OS -- stick when I'm playing through that box too).

Cheers
jimbo

It turns out that pretty much all Shell API based file managers only have partial long path support. Half of the API is there. You can see the folder, move it copy it delete it, but you canot create or rename

"For example these sorts of files only get displayed in 8.3 format in Windows"
Is this drive NTFS ???

- - - Updated - - -

CountMike said:

Maybe not with NAS but in normal conditions TC doesn't revert to 8.3, displays whole name if you widen it
Attachment 250383

Attachment 250384

I have TC too, it is great, nevertheless none of the paths in these screenshots are long file paths. Everything is well under MAX_PATH. Just by eyeballing it, the longest path there should be around 130 chars

- - - Updated - - -


This is a 600+ chars path
C:\Users\UserTest\Desktop\Files\Why didn't Linux or Mac face these compatibility problems Why can't the non-Unicode Win32 file API be extended\ (with some conditions in the existing IO handling functions) to be able to use e.g. MAX_PATH2 = 4096 (or clever dynamic allocation)\The old software will then only use the legacy part of the implementation. But the new software especially Microsoft products (including cmd, explorer, powershell, VS)\should make use of the new features. The OS should shadow all this technical-history Simply use devpathfile.ext and me the OS will decide whats the best choice

A more clear view
C:\
Users\
UserTest\
Desktop\
Files\
Why didn't Linux or Mac face these compatibility problems Why can't the non-Unicode Win32 file API be extended\

(with some conditions in the existing IO handling functions) to be able to use e.g. MAX_PATH2 = 4096 (or clever dynamic allocation)\

The old software will then only use the legacy part of the implementation. But the new software especially Microsoft products (including cmd, explorer, powershell, VS)\

should make use of the new features. The OS should shadow all this technical-history Simply use devpathfile.ext and me the OS will decide whats the best choice


You can move - copy - delete, anything that you can do with "normal paths", but not create, rename. Only part of the API is compatible. it needs further investigation

Under the Hood:
These are the file management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: 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.

Enumerating uses FindFirstFileW-FindNextFileW so there is no question why it is able to see the long path
But CreateFileW is also there. Does the API uses something else?
I 'll have to opt in, and investigate further