Total SQX 1.10 (packer plug-in)

[Clo]

It's the checksum I get from TC when I require. I downloaded the file normally, here it's 20,157 bytes.
- Inside :
TotalSQX.ini = 1068 bytes
liesmich.htm = 52,028 bytes
readme.htm = 46,144 bytes



 FR
Claude
Clo

[Sheepdog]

I can confirm the behavior described by petermad. I must investigate it further later this day.

sheepdog

[petermad]

2Clo

It's the checksum I get from TC when I require

Strange - The checksum I get is also generated by TC.

Here is the checksum I get if I deselect MD5: 82911D9E

[Lefteous]

2petermad
I still wasn't able to reproduce the behavior. I can only guess that this is related to unpack password caching as this is actually the only thing I changed in this beta version.

I will try to disable unpack password caching for non-solid archives.

2Clo

In the case under XP-Pro, that temp dir is quasi-impossible to find out, like I told above, and that doesn't help to see if some files are still in it while they wouldn't…
- Moreover, there is a bloody crappy long path with legion of spaces, that is always boring, I guess. So, a request to Ch. Ghisler in order to use another shorter path to a well known folder easy to reach ?

In most cases it's
C:\Documents and Settings\Clo\Local Settings\Temp\_tc

It's ticklish, but maybe an adjustable timer in the Options, or via INI entries or so ?

This could be done using a timer. I'm not sure if this is the best way. I'm waiting for opinions and other ideas.

[Lefteous]

A new beta (1.07 BETA 5) is ready for download:
http://www.lefteous.de/tc/archives/totalsqx/totalsqx_1.07_beta_5.zip

Expected behavior:
The user will be asked for the unpack password on every single extract operation for non-solid archives. For solid archives unpack password has to be entered once.
Beside that we'll see if this change has any effect on the freeze problem.

[Sheepdog]

I found that it depends on the packed data (and Filenames?) how TC and SQX behave.
Here I provide a bunch of files to reproduce this behavior.

1. Unpack those files to a directory.
2. Pack them with Ctrl+Alt+F5 (Configure: Solid unchecked, Unpack protected with 256 AES. I used Password:ad)
3. Enter the archive
4. Open "wadfile.txt" and delete the first two chars
5. save "wadfile.txt"
6. confirm repacking and enter a new Password (I used "wa" )
7. leave the archive
8. restart TC

1. open the archive
2. open "wadfile.txt" in editor and close without any changes
3. open "AzScript.txt "

Here it takes about half a minute till the Password dilalog appears. Most of the times all the RAM is eaten up (there left 2 MB from 512 In whole and 430MB ususally free).

4. restart TC


1. open the archive
2. open "wadfile.txt" in editor and close without any changes
3. open "Virtuakl keycodes.txt"

The password dialog appears immedately.

4. open "AzScript.txt "

The password dialog appears immedately.

When I replace the content of "Virtuakl keycodes.txt" with that of "AzScript.txt " it also takes half a minute until the password dialog appears for "Virtuakl keycodes.txt".

Hope that helps

sheepdog

[Lefteous]

2Sheepdog
Please always provide the version you used for testing.

[Clo]

Lefteous and All

Hello !

• First, the couple of archives I created to test that 1.07-ß5, available HERE.
- Passwords :
- Listing = LT
- Unpack = UP
- For a third password protecting the addition¦update of files, I used MAJ

- Contain only text files (the same), nothing really private, and in French
Checksum of the ZIP in which I joined the two SQX :

Code: Select all

554eee337f3bcdf6e6b704d876369178 *tests_beta_5.zip

• Solid archive :

- First test, asks for the Listing password once only along the same TC session as expected.
- Edit¦F3 a file : asks for the unpack password, OK. Change ¦repack the file, nothing is demanded.

----------------------------------------------------------------------------------------------------------------------
• Normal archive :

- Open : password demanded for each listing for a first test. But if I close ¦ reopen TC, then I can open the normal archive at will all along the TC session.

- Edit a file >> Changed it >> the new dialogue to protect additions¦updates of files is shown. I have set the 3rd. password quoted above.
¤ Second test : the third password is demanded to edit a file, I gave it, OK.
- But when I tried to edit a second file, I got the new dialogue again, and I guess that this is not normal, since the special password had been defined already…

• Finally, it seems that the global behaviours are much better, but can change a bit between the very first tests in a first session and other tests in other following sessions of TC. I'll see that a bit later…
• Not any delay in the operations here, though.

KR
Claude
Clo

[Lefteous]

2Clo
thanks for testing!

password demanded for each listing for a first test. But if I close ¦ reopen TC, then I can open the normal archive at will all along the TC session.

I cannot reproduce this here. It should be just the unpack password which is requested for each unpack operation not the list password.

But when I tried to edit a second file, I got the new dialogue again, and I guess that this is not normal, since the special password had been defined already…

This is not a special password or a third password. You need to enter a repack password for each repack operation in a non-solid archive. You could set an individual password for each single file in a non-solid archive.

Not any delay in the operations here, though.

Can you confirm this for petermad's archive?

[Sheepdog]

2Sheepdog
Please always provide the version you used for testing.

Sorry, but I neither realized nor expected that there is a new version available. And I simply forgot to mention the version (supposed anyone could guess it's about that petermad was talking about).

Anyway. I did use 1.0.7.0 ß4 for my tests while it seems to be fixed in ß5.

sheepdog

[Lefteous]

2Sheepdog

Sorry, but I neither realized nor expected that there is a new version available. And I simply forgot to mention the version (supposed anyone could guess it's about that petermad was talking about).

Anyway. I did use 1.0.7.0 ß4 for my tests while it seems to be fixed in ß5.

OK sounds good - thanks for testing

Hi,

the problem observed is the following:
The password caching leads to a situation where SQX tries to unpack the file with a password which is wrong for the current file. When a text file is unpacked with a wrong password it needs a lot of time and memory to detect the password entered is wrong in some cases. Sometimes there could be even an out of memory error (this is what I experienced).
To avoid this situation I have disabled the unpack password caching in the latest beta release. Anyway if you enter a wrong password for a file the same problem could happen again. The only workaround is to disable text compression for non-solid archives containing password protected text files.

Anyway I want to ask the users if avoiding such a long delay which happens only in rare cases is better than retyping the password on each unpack operation? In addition the user can avoid this problem by using the same password for all files contained in an archive.

[Sheepdog]

In my opinion it is no problem at all to have this delay in cause of using a wrong password.

One could take this as sort of protection against 'brute force' attacks .

Seriously: A delay when using the wrong password seems to me no unexpected behavior.

And now your plugin prevents apparently the use of the wrong password. BTW: Under certain circumstances the deleting and repacking of the already changed archive lead also to this delay with V 1.0.7.0 4ß. But had not tracked down how to reproduce the behavior.

sheepdog

[Lefteous]

2Sheepdog

And now your plugin prevents apparently the use of the wrong password.

Yes I'm doing this in BETA 5 but the question is if this is really a good idea compared to the necessity to enter the unpack password on each single unpack operation?

[Sheepdog]

Yes, I think this is a good idea.

If I protect an archive with password I would like to prevent it been unpacked by someone, who has no permission.

When I need to edit a bunch of files I can easily unpack them to a temp directory, modify them and repack them to the directory. The I will only be asked once for unpacking and second for repacking for the password.

BTW I have found a way to crash your beta5:

1. Create an archive with textfiles and protectet with password (as described in the post above) PW:ad
2. go into the archive and modify one file.
3. Use a different password to repack the file. PW: ce
4. try to open the repacked file and use the former password for the file: PW:ad

---------------------------
Total Commander
---------------------------
Access violation at address 77C174F0. Read of address A1DA6CB2.
Please report this error to the Author,
with a description of what you were doing when this error occured!
Continue execution?
---------------------------
Ja Nein
---------------------------

And if you press "yes" TC can only be closed via Taskmanager.

If you use a wrong password everythin works well.

sheepdog

[Lefteous]

2Sheepdog

Yes, I think this is a good idea.

If I protect an archive with password I would like to prevent it been unpacked by someone, who has no permission.

When I need to edit a bunch of files I can easily unpack them to a temp directory, modify them and repack them to the directory. The I will only be asked once for unpacking and second for repacking for the password.

I'm sorry I can't follow your arguments. Of course the unpack password is used to prevent others from unpacking files.

. try to open the repacked file and use the former password for the file: PW:ad

What does that mean? Edit the file again and use ad as password?

If you use a wrong password everythin works well.

What does that mean? Using a wrong password works well?