[Bug] File Copy error - TC 7.02a

[g-n-d.net]

Hello

I was trying to copy some files from zipped file to other directory using TC 7.02a, and during copy operation TC reported " writing error", so then I ran ProcessMonitor from microsoft/sysinternals which showed BUFFER OVERFLOW bug as result QuerySecurityFile operation. I documented this problem on screenshots, but unfortunately I can't write link, cause I'm new here and I don't have rights.

[ghisler(Author)]

Please give me some more details. Did the ZIP contain names longer than 259 characters (including the target path)? Total Commander doesn't call QuerySecurityFile, so it must be happening somewhere inside of Windows.

[karlchen]

Hi, g-n-d.net

so then I ran ProcessMonitor from microsoft/sysinternals which showed BUFFER OVERFLOW bug as result QuerySecurityFile operation.

Just to keep you from getting on a possibly wrong track because of the buffer overflow:

It is a common routine used by developpers inside Windows programmes:
+ You wish to query the registry or the file system and store the information in a buffer
+ In order to do so you need a buffer which is large enough to hold the information
+ You do not know how large the buffer needs to be
+ You create a buffer of the size 0 and ask Windows to return the requested information into the buffer
+ Windows realizes the buffer is too small, returns an error and the required buffersize
+ You create a buffer of the specified size, request the information once more and get it successfully.

Therefore, BUFFER_OVERLOWs shown by ProcessMonitor, RegMon or Filemon (all Sysinternals) need not indicate a programme bug or an unexpected error situation at all.
They are often provoked willingly in order to learn the size of a buffer and to allocate a buffer of that size.

(cf. Mark Russinovich on buffer overflows seen in Filemon and buffer overflows seen in Regmon. As ProcessMonitor is Filemon + Regmon + more, Mark's explanation applies to buffer overflows seen inside ProcMon as well.)

Sorry for the lenghty explanation.

Conclusion:

In order to tell whether ProcMon reveals any error related to T.C. it will be necessary to have look at the complete ProCMon log or at minimum at a longer passage. 1 line alone does not mean much.

Karl

[g-n-d.net]

Karl, thanks a lot for your explanation. It's very useful and helpful. I'm really gratefull.

Christian mentioned that problem could be with path length, so I checked it out, and it looks like, in fact, my target path length was greater than 259 characters. Interesting thing is that some files could be copied there and some other couldn't.
In my opinion that magic limit number, I mean MAX_PATH_LENGTH=259 should be increased.

[karlchen]

Hello, g-n-d.net

Christian mentioned that problem could be with path length, so I checked it out, and it looks like, in fact, my target path length was greater than 259 characters. Interesting thing is that some files could be copied there and some other couldn't.
In my opinion that magic limit number, I mean MAX_PATH_LENGTH=259 should be increased.

Well, this MAX_PATH_LENGTH=259 restriction has been a problem for quite a while now.
You may e.g. have look at this thread, BUG: Copy/Move truncates full file names >259 characters.

Interesting enough: This thread has been moved to the TC7 Behaviour which will not be changed forum.

Yet, there seems to be hope, because Christian promised in the thread linked to above:

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...

Kind regards,
Karl

[ghisler(Author)]

The problem is that this 259 character limit exists in many Windows functions. It can be avoided with a special prefix to the name, but this doesn't work with all functions, unfortunately.