That's perfectly okay.
But can you confirm that TC will not truncate any filenames or directory names?
Thanks!!!
(BTW: The public betas are really stable and work very well. Very high quality!)
BUG: Copy/Move truncates full file names >259 characters
Moderators: white, Hacker, petermad, Stefan2
hello christian,
just as rome pointed out in microsoft forum
h*t*t*p://msdn2.microsoft.*com/en-us/library/aa363858.aspx
and
h*t*t*p://msdn2.microsoft.*com/en-us/library/aa365247.aspx
windows can create path longer than 260 caracters and there's no need special tools to do it.
even m$ admited it
"The shell and the file system may have different requirements. It is possible to create a path with the API that the shell UI cannot handle."
just to prove that , and by experience.
just create a very deep tree structure that fills 256 cars eg :
c:\blabla.....\test......\lastdir\myfile.txt
you can see that the last filename length is limited
then share the lastdir and connect it as a local dir , eg : f:
you'll then see f:\myfile.txt
now you can create another 256 caracter length in f:
just copy over the same structure , you'll reach a 512 caracter lenght . thus crossing the 260 cars barrier.
now try to copy the whole structure from c:\blabla.... to another location .
you'll get a big error message . , if you try to browse the whole 512 tree structure by the physical location ( c: ),
you'll see the last file but you won't be able to open ,edit or even view the properties.
any backup software will manage to backup or restore but using tc to copy this kind of structure will fail.
i encountered this problem on many windows file server that holds complex tree structure.
i use tc to migrate data from old server to a new one at office work time , then at night i sync the last modified files.
to be sure everything is complete.
i hope you see what i mean.
would it be possible to implement a file access mode to "traverse" directories (skiping ntfs security, and explorer limits) , in the same way backup programs do?
i'll cross my fingers to see this new functionality soon in tc.
regards
Massimo
just as rome pointed out in microsoft forum
h*t*t*p://msdn2.microsoft.*com/en-us/library/aa363858.aspx
and
h*t*t*p://msdn2.microsoft.*com/en-us/library/aa365247.aspx
windows can create path longer than 260 caracters and there's no need special tools to do it.
even m$ admited it
"The shell and the file system may have different requirements. It is possible to create a path with the API that the shell UI cannot handle."
just to prove that , and by experience.
just create a very deep tree structure that fills 256 cars eg :
c:\blabla.....\test......\lastdir\myfile.txt
you can see that the last filename length is limited
then share the lastdir and connect it as a local dir , eg : f:
you'll then see f:\myfile.txt
now you can create another 256 caracter length in f:
just copy over the same structure , you'll reach a 512 caracter lenght . thus crossing the 260 cars barrier.
now try to copy the whole structure from c:\blabla.... to another location .
you'll get a big error message . , if you try to browse the whole 512 tree structure by the physical location ( c: ),
you'll see the last file but you won't be able to open ,edit or even view the properties.
any backup software will manage to backup or restore but using tc to copy this kind of structure will fail.
i encountered this problem on many windows file server that holds complex tree structure.
i use tc to migrate data from old server to a new one at office work time , then at night i sync the last modified files.
to be sure everything is complete.
i hope you see what i mean.
would it be possible to implement a file access mode to "traverse" directories (skiping ntfs security, and explorer limits) , in the same way backup programs do?
i'll cross my fingers to see this new functionality soon in tc.
regards
Massimo
I personally know that filenames can indeed be much longer than that and I am absolutely sure that Mr. Ghisler knows that, too.
But if he is not able to support long filenames for THIS release (it will surely be done in the next), then I think the only acceptable and correct behaviour of TC is to show errors when it encounters long paths.
Automatically truncating paths would be an absolute no go for a file manager!
But if he is not able to support long filenames for THIS release (it will surely be done in the next), then I think the only acceptable and correct behaviour of TC is to show errors when it encounters long paths.
Automatically truncating paths would be an absolute no go for a file manager!
Hi. What's the current status of the problem? I've read TC7+ supports longer filenames. Sounds like it's fixed? But this bug was filed under "will not be changed" and the last comment of Mr.Ghisler was that he won't fix it before TC7.5 or 8.
I'm confused.
PS: I thought there be problems with the OS (XP in my case) if filenames are too long, or am I wrong ???
Thanks.
I'm confused.
PS: I thought there be problems with the OS (XP in my case) if filenames are too long, or am I wrong ???
Thanks.
New features in Total Commander 7.5 confirmed by the author
(11. Support for very long path names)
NTFS supports longer paths, but most winDOwS programs are limited to 256 characters.
Regards,
Holger
(11. Support for very long path names)
NTFS supports longer paths, but most winDOwS programs are limited to 256 characters.
Regards,
Holger