BUG: Copy/Move truncates full file names >259 characters

[jb]

Windows cannot create files with full names >259 characters. Total Commander 7.0pb2 still does NOT check this restriction when it copies or moves files. So file names are truncated silently if the full names of the destination files would be >259 characters.

Implicit truncation of too long file names is a bug because it is not what the user tells TC to do. If a program cannot execute a command it must inform the user about the exact reason and it may offer alternatives.
In this case TC could offer: Skip, Skip all, Truncate "abc" to "ab", Truncate all, Cancel.

The bug matters because you can lose information without realizing it for example when you make a backup of \root_of_a_deep_tree\ to ...\Backup\root_of_a_deep_tree\ with TC.

I reported this problem already here, years ago!

[byblo]

Indeed, I remember that topic, still waiting for some fix about this bug...

[Jojo]

Yes, I faced this problem too a few times, even introduced bugs in SW installation I made...

It would be nice to have at least some warning when file names are truncated during copy.

[ghisler(Author)]

I decided to truncate them silently because getting an error for every single file would be very annoying...

[byblo]

I decided to truncate them silently because getting an error for every single file would be very annoying...

I do not understand your point of view. How can you accept that a program truncate filenames silently ? It destroying partially their organization, and sometimes losing informations contained in the filename. For a file manager this sound weird (this is not an insult).

[sas2000]

 

I decided to truncate them silently because getting an error for every single file would be very annoying...

If i have to choose between very annoying & extremely dangereous i prefer the first one.

Please add an option on Wincmd.ini to be able to deactivate such Tc behaviour.

I'm a great Tc fan but truncate filenames silently and the possibility of losing data when using it is absolutely unacceptable, thanks.
 

[Lefteous]

2ghisler(Author)

I decided to truncate them silently because getting an error for every single file would be very annoying...

Well the thread starter has suggested "truncate" and "truncate all" functions.

[karlchen]

Hello, Christian,

I must say that I agree with jb's request.

Silently truncating names is not even really your style, as you often stress your motto of "safety first". (Appreciated most of the time)

And with the option dialogue suggested by jb, the annoyance would be reduced to the inevitable minimum, unless the user selects to be asked for each too long name separately.

Karl

[jb]

In this case TC could offer: Skip, Skip all, Truncate "abc" to "ab", Truncate all, Cancel.

I decided to truncate them silently because getting an error for every single file would be very annoying...

I have the impression that you missed my suggestion after reading my criticism.
Numerous warnings (not errors) might be very annoying only if TC did not offer the buttons Skip all and Truncate all. But even without these convenience buttons TC's behavior would be far better than now because the case of too long file names is rare and when it occurs then usually something is terribly wrong! So you have to Cancel the operation, correct the problem and start all over again. However with the current behavior typically you realize the problem only much time after the operation. And then the correction tends to be more expensive if possible at all.

Please introduce an option "AskUserBeforeTruncatingTooLongFileNames" with default value 0 (=no) if you still think that the current behavior is preferable. If the option value is 1 (=yes) and logging is enabled then each skipped or truncated file should also be logged as warning. Also the cancel operation should be logged.

[sas2000]

 
2ghisler(Author)

As karlchen said ,"safety first", every Tc upgrade has more and more useful features, but its primary function is to manage files and under no circumstance data could be lost without previous warning.

Time ago you solved a problem with an Adaptec SCSI controller, where the big file copy mode was causing corrupted files, and this problem prevented you to set copy method configuration to get maximum safety when copying files, obviously this problem is different but the possibility of losing data is the same. Thx.
 

[sas2000]

 
If you want to know if you can have problems with long full names silently truncated by Tc, you can use Filename ChrCount content plugin or DirEx (28 Kb) in German language.

Maybe we can create a poll to know which one of us is closer to 259   , i have found a chess database file with full name = 244 characters.
 

[wanderer]

Hello, Christian,

I must say that I agree with jb's request.

Silently truncating names is not even really your style, as you often stress your motto of "safety first". (Appreciated most of the time)

And with the option dialogue suggested by jb, the annoyance would be reduced to the inevitable minimum, unless the user selects to be asked for each too long name separately.

Karl

Well said. I agree 100%.

[rome]

Windows cannot create files with full names >259 characters.

That's wrong Windows itself can create them.

see:

h*t*t*p://msdn2.microsoft.*com/en-us/library/aa365247.aspx

The Unicode versions of several functions permit a maximum path length of approximately 32,000 characters composed of components up to 255 characters in length. To specify that kind of path, use the "\\?" prefix. The maximum path of 32,000 characters is approximate, because the "\\?" prefix can be expanded to a longer string, and the expansion applies to the total length.

it's only needed to be implemented ^^

See:

CreateFile
h*t*t*p://msdn2.microsoft.*com/en-us/library/aa363858.aspx

HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);
Parameters
lpFileName
[in] A pointer to a null-terminated string that specifies the name of an object to create or open.

In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\\?" to the path.

I'd like to see Total Commander could handle and work with long file paths.
But there should be a info messages when creating such a structure and
when trying to call a file with an association which has a long file path
(Because most application can't handle long file paths - but there are
some, that can).
(A option to turn this info off for the active session would be nifty.)


rgds
Robert

[atesti]

Are you serious that this very bad bug is placed under "behaviour which will not be changed"?

While support for 32000 long filenames would be a great addition and the best solution, the old behaviour of NOT silently truncating filenames was the correct behaviour!

I cannot use Total Commander if it silently distroys important data and a filename and exact folder strcuture is very important data!

What did you think???

Image a fine grained, important folder structure at the end of a very deep path! would you destroy this into s.th. like ....blah\01.1??

Or has this already been fixed?

[ghisler(Author)]

Since names longer than 259 characters can only be supported with Unicode functions, I will handle this problem when moving everything to Unicode in TC 7.5 or 8. It makes no sence to cripple it now and re-add later...