ZIP corruption on Esc during repacking on USB stick

[Flint]

Flint, as I described above, I add a file into ZIP on a USB stick. TC creates modified archive in a temp folder and then copies it instead of original one.

That's exactly what I was talking about! If RemovableInTemp=0, TC will create the modified archive not in TEMP, but directly on the same USB stick, beside the original archive, anc the copying step will become superfluous.

I don't perform such operations frequently (in fact, I'm using 7Z and CAB archives usually) but TC should allow to continue process after false Escape if it shows some message.

Absolutely no objections to that, rather the contrary.

[MVV]

That's exactly what I was talking about! If RemovableInTemp=0, TC will create the modified archive not in TEMP, but directly on the same USB stick, beside the original archive, anc the copying step will become superfluous.

It seems that it is not true because I have a disproof.

I've tried TC 7.04a, TC 7.56a, TC 8b22x32 with clean INI and all of them pack to temporary folder and then replace original archive with updated one! BTW it happens even if I directly set RemovableInTemp=0 in [Packer] section of wincmd.ini.

Tested on Win7x64ProSP1.

[petermad]

RemovableInTemp=0 only has effect for small media like floppies - for larger media (ZIP, JAZ) packs directly on the media without the TEMP dir

[Flint]

I've tried TC 7.04a, TC 7.56a, TC 8b22x32 with clean INI

I saw this, but I'm talking about my personal experience, confirmed by the description in the help file. I tested it on XP SP3 x32 with TC 8.0β22 x32, and on Win7 SP1 x64 with TC 8.0β22 x32+x64: when RemovableInTemp=0 the temporary file is created directly on the flash disk.

Maybe, you found some bug and TC detects your particular flash disk on your particular system as something that needs using TEMP dir always — OK then, but report it in another thread, because this just must not be so. And here this problem only makes things more complicated. What we need here is to help Christian reproduce this problem, and RemovableInTemp=1 (according to the original design and help file description) is the mandatory prerequisite. In some cases the problem can be reproduced with RemovableInTemp=0 — OK, so be it, but it's a totally different story. We already know that on Ghisler's computer this is not the case, so why confuse matters further? He already has many reports to deal with, and we should help him by splitting different bug reports instead of mashing them together. The steps to reproduce each problem must be as universal as possible. With RemovableInTemp=1 the problem is reproduced with guarantee, with RemovableInTemp=0 — only on some computers (and at the moment these "some computers" include only yours). So I just tell: set RemovableInTemp=1 and you will definitely see what we were talking about. Plain and simple.

[ghisler(Author)]

Actually you have to set RemovableInTemp=1 (not zero!) to reproduce the problem, because only then TC has to copy the file.

OK, I can try to add Cancel button. Maybe I should also delete the damaged zip and keep the one in TEMP if the user still clicks on OK?

[Flint]

OK, I can try to add Cancel button. Maybe I should also delete the damaged zip and keep the one in TEMP if the user still clicks on OK?

Probably yes, but IMHO user should be notified about this. Intuitively user expects to find the original archive unchanged when he presses Cancel (he might not know about technical side of the operation), and he might be surprised to see it completely removed. He should know that his data remained intact but are located in different place.

[ghisler(Author)]

Unfortunately that would require a new translation.

[Flint]

ghisler(Author)
As a temporary solution the line 1230 would do. In the next major update you'll be able to add a separate line for this case.

[ghisler(Author)]

I found a better solution: First I show "User abort" with OK and Cancel buttons. If the user clicks OK, I show string 1134, which is shown anyway in this case if the copying fails for some other reason.

Btw, the TEMP file isn't deleted when the user aborts the move operation now, so there is no data loss.

[Flint]

I found a better solution: First I show "User abort" with OK and Cancel buttons. If the user clicks OK, I show string 1134, which is shown anyway in this case if the copying fails for some other reason.

There is only one %s, which of the paths do you intend to show there, the TEMP one or the target archive's?

Btw, the TEMP file isn't deleted when the user aborts the move operation now, so there is no data loss.

I know that, you know that, but all other users should also know that. Even if you just tell somebody "Don't worry, your data are safe", the very first question from him will be: "OK, fine, but WHERE ARE THEY???"

[ghisler(Author)]

WHERE ARE THEY?

Well, that answers your first question, what would be shown in place of %s.

That's already done now in case of a write error, so the user knows where to find the complete archive - just not in case of a user abort.

[Flint]

OK, that eliminates my concerns then.

[MVV]

Great, works perfect in beta 23! Both cancel dialog and error message on interrupt.

[Flint]

Confirm too.

[ghisler(Author)]

Thanks!