Page 1 of 1

I'd wish for better long filename support

Posted: 12.10.2017, 11:11
by lloser
Hi Marek,

I'm using FC in a professional environment where users often reorganize their file- and directorystructure and occasionally they create super-long filenames , i.e. > 260 characters (path+actual filename combined), as a result. I can not dive into such directories or copy them directly without shortening them first. But to do that, I have to find them first ... :evil:

Using Ghislers Total Commander, treating super-long filenames/directories directly proves not to be a problem, so there is a way to circumvent the troubles alltogether by means of programming. NTFS itself seems to support up to approx. 32.000 char per entry? I read somewhere, there exists a particular Unciode Windows API to make use of in programming? Don't know what that means, though :cry:

So beyond your "basic" long-filename support, I'd wish for rather "extended" long-filename support!

Thx in advance,
lloser
Using FC public beta 760

Re: I'd wish for better long filename support

Posted: 12.10.2017, 20:53
by Marek
What is missing in the "basic" support. What can not you do?

Re: I'd wish for better long filename support

Posted: 22.11.2017, 17:48
by Forez
Marek wrote:
12.10.2017, 20:53
[...]
What can not you do?
I also have a similar problem on Windows 7 x64 with NTFS file system and a proof that this problem is recognized [averted] by a third part software

Sometimes I have long names of files and I put them in many subfolders- meaning that each next subfolder gets me closer to the length limit. So OK, so I can always stop [or will be stopped] at some point. But what happens if I want to copy the whole structure to another folder, which requires adding even more signs "to the equation"? I get an info, that the path would be too long

My backup software was designed with this problem in mind- it creates ZIP files. So I can create a ZIP and automatically put it in another folder. So the problem of the too long names is subdued [hidden] within the ZIP file. And what happens if I use FreeCommander for exploring than ZIP file [thus re-creating a too long path, being constructed of the original path and the name of the ZIP and the folder in which this ZIP is stored]? I can go to the very end- but if I will try to access the file [now exceeding the length limit] a FreeCommander "Native error: 00019" appears



This problem of too long paths is also roaming the Windows itself. There are problems with executing deletion on them. And even after that, the $RECYCLE.BIN folder stores indefinitely structures exceeding the limit; only sometimes somehow temporarily hiding them. Aside from formatting the whole drive they can be only removed with the whole Recycle Bin folder itself; and than can be achieved within CMD with this command

rd /s /q c:\$Recycle.Bin

where the "c" of course stands for the drive C

[The $RECYCLE.BIN folder, will reappear after deleting something new and / or after a system reboot, so do not worry about messing up your Windows]