I'd wish for better long filename support

Suggestions and feature requests.
Post Reply
Message
Author
lloser
Posts: 5
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: 2739
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: 440
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]

klausisbruch
Posts: 5
Joined: 10.10.2016, 11:40

Re: I'd wish for better long filename support

#4 Post by klausisbruch » 29.01.2020, 13:03

Marek wrote:
12.10.2017, 20:53
What is missing in the "basic" support. What can not you do?
I have a build system for java programming, and java is notorious in working with veeeery long path/filenames, by creating many subdirectories.
Quickly, the current length limit of the latest FreeCommander donor version is exceeded, especially if attempting to copy or move the whole directory tree to some folder, which also already sits several subfolders deep.

Funny thing is, I can walk down such a veeery long directory tree in FreeCommander, but I cannot use FreeCommanders copy or move functions to get files there.

The request for FreeCommander is to support the path/filename length supported by the file system, which is 32.000 characters for NTFS, for copy/move/delete/zip/unzip/find,... etc.
Thanks, Klaus

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

Re: I'd wish for better long filename support

#5 Post by Forez » 19.02.2020, 20:09

On a side note in regards to
Forez wrote:
22.11.2017, 17:48
[...]
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]
If you put this script in a BAT file and find out that the BAT executes itself but the Recycle Bin folder is not deleted after all, you need to:

create a shortcut to it, right click that LNK file, go to Properties > Shortcut > Advanced and select "Run ad administrator". And from now on use that shortcut instead of the BAT itself



Alternatively instead of CMD you can use a free software FastCopy, which can delete Recycle Bin folders

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests