I'd wish for better long filename support

Suggestions and feature requests.
Post Reply
Message
Author
lloser
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,
lloser
Using FC public beta 760

Marek
Author
Author
Posts: 2137
Joined: 10.04.2006, 07:48
Location: Germany
Contact:

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?

Forez
Posts: 127
Joined: 30.01.2016, 11:05

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 folder in which the 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 "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 Recycle Bin folder itself; and than can be achieved within CMD [for drive C] with this

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

[The $RECYCLE.BIN folder, will reappear after deleting something new and / or after a system reboot]

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests