Copy of long path with plugin interrupts all process

The behaviour described in the bug report is either by design, or would be far too complex/time-consuming to be changed

Moderators: white, Hacker, petermad, Stefan2

Post Reply
User avatar
b1Ack
Junior Member
Junior Member
Posts: 18
Joined: 2013-07-22, 02:16 UTC
Location: Donetsk

Copy of long path with plugin interrupts all process

Post by *b1Ack »

I used TC with DiskInternals reader plugin to copy an HFS+ drive content to normal NTFS drive and encountered a bug.

If I select for copying folder, that contain a very long path subfolders (259+ symbols) - in the middle of process appears dialog - what I want to do with that. Ok. I select "Save all" because I don't care about compatibility with old software in this case - and damn, all copy process is interrupted on this step. Yes, completely interrupted, just like I press "cancel" button instead of selecting what to do with long path. I also tried just "Save once" button - with the same result. Of cource I expected usual continue of copying with selected options - remember not to ask me about long path or do so on next item, but no process stop.

I then updated DiskInternals reader to a latest version - with no visible changes, bug is still here.

* I not sure about "Save all" and "Save once" literally naming of buttons because I use russian version, but hope you understand what I mean.
Last edited by b1Ack on 2017-08-10, 09:19 UTC, edited 1 time in total.
User avatar
tuska
Power Member
Power Member
Posts: 3740
Joined: 2007-05-21, 12:17 UTC

Post by *tuska »

Help - F1 wrote:LongNameCopy=0

During file operations, warn if target name is longer than 259 characters:
0=always
1=never
2=if source name isn't longer than 259 characters
3=disallow long names
In wincmd.ini this entry under [Configuration] could help you:

Code: Select all

LongNameCopy=1
User avatar
b1Ack
Junior Member
Junior Member
Posts: 18
Joined: 2013-07-22, 02:16 UTC
Location: Donetsk

Post by *b1Ack »

Thank you!
Already done all manually with shortening target path,
but will save info from your post for future use.
And this is only a way how to override the bug, but not a fix.
User avatar
tuska
Power Member
Power Member
Posts: 3740
Joined: 2007-05-21, 12:17 UTC

Post by *tuska »

b1Ack wrote:And this is only a way how to override the bug, but not a fix.
This is not a bug, but a Microsoft Windows limitation!
User avatar
b1Ack
Junior Member
Junior Member
Posts: 18
Joined: 2013-07-22, 02:16 UTC
Location: Donetsk

Post by *b1Ack »

Windows limitation is that Total Commander can't copy remaining files when meet at least one with very long path, and user select to save path once or save this and all others? That's sounds ridiculous. I updated 1st post to be more clear. Hope my english is not so bad so we can understand each other.
User avatar
tuska
Power Member
Power Member
Posts: 3740
Joined: 2007-05-21, 12:17 UTC

Post by *tuska »

This windows restriction is treated in TC with LongNameCopy (please see above).
Did you try: LongNameCopy=1 ?
User avatar
b1Ack
Junior Member
Junior Member
Posts: 18
Joined: 2013-07-22, 02:16 UTC
Location: Donetsk

Post by *b1Ack »

Can't check for now because already did what was needed and have no unix filesystem file source - original one was cleared.

Tried to reproduce bug with archive as source - in this case all is fine, copy progress continues after I make selection what to do with long path.
So looks like that bug is only for FS plugins.
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

If you haven't set LongNameCopy=1 in wincmd.ini, TC will warn you at least once for every separate copy/move operation, you can't tell to TC to ignore long names in further copy/move operations.
User avatar
b1Ack
Junior Member
Junior Member
Posts: 18
Joined: 2013-07-22, 02:16 UTC
Location: Donetsk

Post by *b1Ack »

Thank you, Cpt. Obvious! That works fine for usual copy operation and for copy from archive, but not works when copy from unix FS via FS plugin. Maybe it can be overrided using tuska's advice, but I have no source anymore to check it again.

MVV, копирование прерывается когда я делаю выбор что делать с длинным именем. Совсем прерывается. Как будто я его отменяю, а не решаю что делать с длинным именем файла. Это не есть норма а самый натуральный баг. Разве что я не в курсе, воспроизводится ли он со всеми ФС-плагинами или только с одним, указанным в первом посте. Но его обновление на самый свежий точно не работало.
User avatar
Hacker
Moderator
Moderator
Posts: 13052
Joined: 2003-02-06, 14:56 UTC
Location: Bratislava, Slovakia

Post by *Hacker »

[mod]b1Ack,
English only, please. Not many people here can help you if you write Russian. If you prefer Russian anyways, there is a dedicated Russian forum.

Hacker (Moderator)[/mod]
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

b1Ack wrote:MVV, копирование прерывается когда я делаю выбор что делать с длинным именем. Совсем прерывается. Как будто я его отменяю, а не решаю что делать с длинным именем файла. Это не есть норма а самый натуральный баг. Разве что я не в курсе, воспроизводится ли он со всеми ФС-плагинами или только с одним, указанным в первом посте. Но его обновление на самый свежий точно не работало.
Translation (the same was described in first post):
Copying is interrupted regardless of answer on TC warning about long file path, just like Cancel button is pressed. It is obviously a bug. The only question is all plugins affected or only some. The most recent DiskInternals plugin version has been used for testing.
b1Ack,
I can tell some details regarding FS plugins: every FS plugin realizes copying files itself, TC only tells source and target file paths. But in case of names longer than 259 characters in length some special handling is required (special prefix must be added to such long names) otherwise Windows API fails. So if a plugin doesn't support long paths, it have to be updated in order to add such support, and it is not a TC bug. Windows API requires this prefix as a mark that program supports long names.
Post Reply