TC overwrites w/o ask on unpack to some folders

[MVV]

You can test it with C:\Windows\Temp folder, it doesn't allow users to list files but allows to create/modify existing ones.

Using user account try to copy any file into C:\Windows\Temp folder (you may need 'as admin' button to enter folder before). And then try to copy file with same name into it - TC asks for overwrite. Now try to unpack file with same name into C:\Windows\Temp - TC overwrites w/o ask!

It is expected that TC will ask user if he wants to overwrite file.

Same behaviour occurs on WXP and W7.

[wanderer]

You can test it with C:\Windows\Temp folder, it doesn't allow users to list files but allows to create/modify existing ones.

That's not true. I can list files too. Maybe because i'm admin...

Now try to unpack file with same name into C:\Windows\Temp - TC overwrites w/o ask!

TC's unpack dialog has an "Overwrite existing files" option.

[MVV]

That's not true. I can list files too. Maybe because i'm admin...

You can test it with C:\Windows\Temp folder, it doesn't allow users to list files but allows to create/modify existing ones.
...
Using user account try to copy any file into C:\Windows\Temp folder (you may need 'as admin' button to enter folder before).

Admins just can list files so bug is not visible. You need limited account.

TC's unpack dialog has an "Overwrite existing files" option.

As I wrote, I do both tests one by other and don't change any options, and when I unpack to one folder TC asks to overwrite but when I unpack to another folder TC doesn't ask.

[ghisler(Author)]

I'm sorry, it's currently not possible to handle that situation of a folder where reading is forbidden but writing allowed. Why? TC has to check before unpacking a file whether the target exists or not. This is unfortunately not possible when reading from the target is impossible.

Edit: It seems that there is a way to check it - via CreateFile (for reading). TC uses FindFirstFile because it's much faster, but I can revert to CreateFile if the access is denied.

[MVV]

Maybe TC should use GetFileAttributes instead of FindFirstFile? I think it will be even more faster since no handle is used and no data returned besides attributes.

[ghisler(Author)]

I'm using all 3, in a mix which has been proven to work in many situations (except for the above). I will not change this now just before the release, sorry.

[MVV]

Well, if no one hadn't reported this before it isn't frequently used:) but I think you'll fix it before releasing TC 8.

[ghisler(Author)]

No, of course I fix it already in TC 7.55 - it's easy, just check with CreateFile when FindFirstFile returns error 5 (access denied), just as I do now in case of error 0 (file found).

But I will not switch to GetFileAttributes instead of FindFirstFile, this could have unpredictable results.

[romulous]

Hm, interesting. Sounds similar to the bug I reported a while back where in some cases TC will overwrite a file without prompting when a CTRL+S filter is active in the destination folder when you do a file move from one folder to another. Obviously not the same circumstances as in this case, but the same effect - the file overwriting dialog is suppressed. Oh well, bugs happen I suppose.

[ghisler(Author)]

2romulous
Unfortunately I could not reproduce your problem. It's completely unrelated, because TC doesn't look in the target panel list whether a file exists or not. TC looks directly on the harddisk, so the state of the Ctrl+S function doesn't matter.

[MVV]

Thanks, bug is fixed in 7.55 final.

[ghisler(Author)]

Thanks!