F3 overwrite warning

[Dark-Star]

Sometimes, when pressing F3 to view a file inside an archive, I get the "overwrite?" dialog prompting me to confirm overwrite of the temp file. That's a bit annoying, TC should always override these files.

There's more: When I click on "Overwrite" and then scroll down in the viewer, I get a "File not found" error (provided that the file is big enough so that it's not entirely read into meomry on viewing, 2mb at least will do the trick).

To recreate this problem, open a ZIP file and press F3, ESC, F3, ... a few times until you get the overwrite prompt. Click on "Overwrite" and then press PgDn a few times in the viewer -> Error message

[ado]

Dark-Star,

Sometimes, when pressing F3 to view a file inside an archive, I get the "overwrite?" dialog prompting me to confirm overwrite of the temp file. That's a bit annoying, TC should always override these files.
...
To recreate this problem, open a ZIP file and press F3, ESC, F3, ... a few times until you get the overwrite prompt.

That warning is ok. I cannot reproduce it in a way you are suggesting F3, Esc, F3,.... but if by accident you hit once F4, you'll get it. The problem is that you can open in each panel different zip file and try to view different file with the same name. In that case warning is appropriate. Also when you open file from zip (or FTP) to Edit it, then you switch back to TC without closing of editor and you press F3, warning is more than appropriate.

but...Christian, open zip file in different panels should temporary extract files into different directories - the same as with FTP.

...it's not entirely read into memory on viewing, 2mb at least will do the trick

no, it will not do the trick. You can use TC built-in viewer to view files with GB in size. It always read into memory just small portion of file that you see (yeah sure, probably little bit more, but definitely not whole file). More it looks to me like you opened one big file in viewer, then you overrode it with small and you switched back to big one and wanted to scroll to bottom. Sure in that time there was different file.
Probably TC should close viewer with bigger file in that case, or something of that sort

ado

[Dark-Star]

I will try to create a video with the behavior, as it is perfectly reproducible here. I didn't press F4 by accident, and the file is not overwritten with a smaller file (since it's always the same file which I try to view)

Anyone know of a good and free tool to do video captures of a window?

[batchman61]

as far as i remember

http://sourceforge.net/projects/camstudio/

was recommended in the forum (no experience myself)

pack the output with sqx for best compression result

[Hacker]

Dark-Star,

Anyone know of a good and free tool to do video captures of a window?

Please create videos (or screenshots) of bugs when possible!

HTH
Roman

[Dark-Star]

Ok, I think I know what's going wrong: TC doesn't delete the extracted tempfile right after pressing ESC in the viewer, but rather a second or so after the window is closed. Now if you try to view the same file again *very quickly*, it gets uncompressed over the already existing file (which has not been deleted) and after the viewer shows the file, TC silently continues to delete the old file, so you get the error after scrolling down a bit.

I uploaded a video here: 450 kb .sqx file

What I'm doing in that video is exactly what I described in my first post: open a .zip file, view a 250kb .pdf file with F3 (I scroll down to the end of the file to show that everything works fine), then quickly press ESC followed by F3 again (still on the same file). After confirming the overwrite, I try to scroll down to the end of the pdf file using the PgDown key -> Error.

Note that the "quickly" part is essential, if I wait a few seconds after pressing ESC and before F3, everything works as expected. Maybe the bug is harder to trigger on faster hardware, I have an Athlon XP2400 and a Pentium-M 1600 on both of which I have no problem of re-creating this behavior.

Hope that helps in nailing down the bug.

[szlori]

Confirmed.

[ghisler(Author)]

Unfortunately this cannot be avoided. There are dozens of cases when the temp file is no longer needed, which is handled by a timer. It's simply not possible to delete the file immediately.

[Dark-Star]

So why does it work correctly in TC6? Also, what are those cases where you still need the temp file after closing the viewer?

[jb]

Unfortunately this cannot be avoided. There are dozens of cases when the temp file is no longer needed, which is handled by a timer. It's simply not possible to delete the file immediately.

You can avoid the problem by appending a unique key to the name of the temporay file.
I also encountered the problem some time ago in JScript scripts and solved it this way.
The unique key may be generated for example by concatenating the current time in milliseconds and a random numer, both expressed with radix 36 (0..9, a..z) to reduce the length of the key. I'm not an expert in this field. Please let me know if you know a better implementation.
I suppose the random number is not necessary in Delphi when you use the Win32 function QueryPerformanceCounter() as current time.

[szlori]

Unfortunately this cannot be avoided. There are dozens of cases when the temp file is no longer needed, which is handled by a timer. It's simply not possible to delete the file immediately.

Maybe the overwrite dialog can't be avoided...
However, you should make sure to avoid the error on PgDown later.
That looks no less than a bug.

[jb]

Maybe the overwrite dialog can't be avoided...
However, you should make sure to avoid the error on PgDown later.
That looks no less than a bug.

I assumed that the problem is caused by viewing the same file within an archive twice very quickly (within a fraction of second). Each time TC extracts the file from the archive into a temporary file with the same name and finally deletes the temporary file (clean up). But the deletion takes some time. So there is a race condition, that is, the re-extraction of the file can occur before the deletion which leads to overwriting. To avoid that I suggested to make the name of the temporary file UNIQUE by appending a different key on each extraction. This solves both phenomena (overwrite dialog and PgDown error) since they are closely related.

[Dominus]

it can also happen when you view two files of an archive with the same filename.
This message popped up sometimes for me and also with the 6.x version. I don't think it's too bad and actually a good idea to prevent accidental overwrites.

[ghisler(Author)]

So why does it work correctly in TC6?

This can't be, TC6 and TC7 use the same mechanism! Did you really do the exact same thing?

[Dark-Star]

I just tried it again with TC6 (6.53 to be exact, since I don't have a newer version at hand right now -- I'll try a newer version later today) and compared it to TC7.

TC7 immediately shows the "overwrite" box on the first try (F3->ESC->F3->overwrite box), with the error message mentioned above. In TC6, however, I couldn't reproduce this behavior at all (and I cannot remember it *ever* happening, and I've used TC since its Windows Commander 4.5 days...). Same zip-file, same directory, same computer.

@ghisler: can you really not reproduce the problem on your setup? Maybe it has already been fixed by some other bugfix and it isn't in beta3 anymore? Also: why use a timer to delete the file anyway? Can't you delete the file immediately after the viewer closes (TC can wait on the process handle of the viewer process)