BUG: Copy truncates file names >259 chars!

jb · Post by *jb » 2004-03-21, 22:32 UTC

TC 6.02 truncates file names >259 characters if their full directory name is <=247 characters.
(Otherwise TC just says: "Error: Directory [YourDirectory] not created!")

EXAMPLE 1:

Code: Select all

REM Test very long file names
SET s10=1234567890
SET s20=%s10%%s10%
SET s50=%s20%%s20%%s10%
SET s100=%s50%%s50%
SET s240=%s100%%s100%%s20%%s20%
MKDIR C:\%s240%
DIR>  C:\%s20%
COPY  C:\%s20%  C:\%s240%\

COPY says: "The file name is too long. 0 file(s) copied." I think that's correct.

When using the Windows Explorer the copy operation fails too. It says: "Cannot copy 12345678901234567890: The file name you specified is not valid or too long. Specify a different file name."

When using TC 6.02 the copy operation succeeds, but C:\%s20% is copied to C:\%s240%\123456789012345 truncating the full file name to 259 (=3+240+1+15) characters.

EXAMPLE 2:

Code: Select all

REM Test very long file names
SET s10=1234567890
SET s20=%s10%%s10%
SET s50=%s20%%s20%%s10%
SET s100=%s50%%s50%
SET s230=%s100%%s100%%s20%%s10%
MKDIR C:\a\%s230%
DIR>  C:\a\%s230%\%s20%
XCOPY C:\a C:\Backup\a\ /E

XCOPY says: "Insufficient memory. 0 File(s) copied." I think that is correct, although not very informative.

When using the Windows Explorer the copy operation succeeds, but C:\a\%s230%\%s20% is copied to C:\Backup\a\%s230%\123456~1. That is, the last part is abbreviated to the short name 123456~1 to prevent overflow.

When using TC 6.02 the copy operation succeeds, but C:\a\%s230%\%s20% is copied to C:\Backup\a\%s230%\1234567890123456 truncating the full file name to 259 characters (MAX_PATH-1 in windef.h).
NOTE: This case shows a real danger: When you make a backup of a deep tree with TC 6.02 there is a slight chance that you lose information without realizing it!

IGL · Post by *IGL » 2004-03-22, 12:32 UTC

Yes, this problem occures, additionally I had problemd deleting such created directories/files with TC (but command line helped).

I understand that TC cannot handle too long names, this limitation of Windows. I do not consider it as a bug.
But I do agree that a bug is the fact that TC does not provide any warning message. TC should inform a user that name is too long and will be (or was) truncated

jb · Post by *jb » 2004-03-22, 19:46 UTC

IGL wrote:Yes, this problem occures, additionally I had problemd deleting such created directories/files with TC (but command line helped).

I had no additional problems. Can you explain them more exactly?

IGL wrote:I understand that TC cannot handle too long names, this limitation of Windows. I do not consider it as a bug.

Of course 259 (or 260) is Windows' limitation for non-Unicode file names. I already mentioned MAX_PATH in windef.h. Nevertheless I consider TC's behavior (implicit truncation of too long file names) a bug because it is not what the user tells it 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.

IGL · Post by *IGL » 2004-03-23, 11:22 UTC

2jb
I had problems when deleting such created files, but I have performed some command line operations manually. Description follows:
Run the script number 1 crating 12345... file and 12345..... directory.
Then enter the directory and type in command line:
command.com , you will get the prompt: "c:\123456~1>" , then type:
copy C:\12345* . - there is a (space and dot at the end)

This operation will be executed because I am working on SFN (Short File Name) of directory and It actually results with file:
C:\123456~1\12345678901234567890 - which is acceptable by OS.
But when viewing this under TC you get c:\12345678901234567........\12345678901234567890
And therefore this file cannot be deleted.
You have to use command.com to enter the directory C:\123456~1:
and you need to type del *.* /p
TC cannot delete it. Similiar things may occure if you have nonstandard characters in filename (different language version or corrupted directory).
I do not consider it as a bug,
In order to do it with TC it would need to switch to operate in short file names.
But I just run command.com and do it with del.

I guess old Norton Commander - NC would be able to do it, because it operates on short file names

Dark One · Post by *Dark One » 2004-03-24, 01:13 UTC

uh, guys, why are you spending time on finding theoretical bugs in commander? it is normal that it doesn't work with 260+ filenames. all programmers use MAX_PATH (=260) constant for allocating memory to hold filenames and dont care for the case of longer filenames. so, having a filename that long is very stupid idea, because 80% of the programs will fail to work with it.

don't take this as an offense.

IGL · Post by *IGL » 2004-03-24, 07:05 UTC

Dark One, I agree with you. No sense to make discussions about that.
It is not a problem that TC does not work with too long filenames.
But there's just one thing being a result of this post, what some of us do expect is:
Let TC inform a user when too long file name cannot be handled

jb wrote: 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.

byblo · Post by *byblo » 2006-10-15, 07:27 UTC

The worst is when you copy 2 files with the same starting string, like abcd1.x and abcd2.x, there is a risk that one replace each other, if resulting filename is truncated as something like : ab (fortunately, tc ask you if you want to replace the first by the second...)

Yes its rare, I've got this problem only 2 or 3 time since years, but the risk is real.

As a file manager for windows, its sound to me weird that tc didn't fix that kind of things.

I agree with IGL

levicki · Post by *levicki » 2006-10-17, 14:08 UTC

Dark One wrote:uh, guys, why are you spending time on finding theoretical bugs in commander? it is normal that it doesn't work with 260+ filenames. all programmers use MAX_PATH (=260) constant for allocating memory to hold filenames and dont care for the case of longer filenames. so, having a filename that long is very stupid idea, because 80% of the programs will fail to work with it.
don't take this as an offense.

You know, there is a way to use Unicode strings and APIs and long paths, you just need to add "\\?" in front of the path. So, not all programmers do it. By the way, most APIs that return strings/paths in Windows can be queried by passing NULL pointer to the buffer first and then the API returns number of characters needed for a particular string which you can allocate dynamically.

Anyway, I agree about the part that it should either warn the user and give some options to control what will happen or reject the operation completely like system commands do.