I'd wish for better long filename support

Suggestions and feature requests.
Post Reply
Posts: 3
Joined: 20.03.2015, 11:56

I'd wish for better long filename support

#1 Post by lloser » 12.10.2017, 11:11

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,
Using FC public beta 760

Posts: 2274
Joined: 10.04.2006, 07:48
Location: Germany

Re: I'd wish for better long filename support

#2 Post by Marek » 12.10.2017, 20:53

What is missing in the "basic" support. What can not you do?

Posts: 252
Joined: 30.01.2016, 11:05
Location: In front of a PC monitor

Re: I'd wish for better long filename support

#3 Post by Forez » 22.11.2017, 17:48

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]

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests