Total SQX 1.10 (packer plug-in)

Lefteous · Post by *Lefteous » 2006-03-05, 19:47 UTC

2petermad

I don't know if that is of any help?

Not really. I have never heard of such a file. What is inside the file? Garbage?

Post by *petermad » 2006-03-05, 20:41 UTC

What is inside the file? Garbage

Yes it seems like it is only garbage - mixed binary and text.

I just checked my temp dir with an unerase tool - there actually seems to have been several directories like that one with the two mentioned files - the directories were all dated today, but whether or not they are related to my recent testing of the SQX plugin i cannot tell.

It is actually not quite true that my TC hangs. It is just frozen for several minutes - where this disk activity goes on - after that the dialog pops up again asking for the sqx password. While this is going on, the title of my TC changes to: "[2] Total Commander..." - as if a second instance of TC is suddenly running.

A few times I got the same behaviour as you - the password dialog just popping up again and again (with no delay)..

After these incidences my whole system seems rather f....d up - like it is running on virtual memory with a lot of disk swapping. If I check the free memory with cm_SysInfo it says that I have 70% free memory though - wich is very odd indeed, because I only have 44% after a clean boot!

If I try to kill TC during the freeze (after having entered the new sqx password) Task manager shows 2 instances of TC running! - and it takes several retries to kill TC.

Lefteous · Post by *Lefteous » 2006-03-05, 21:02 UTC

2petermad
How large is the archive you have used for testing?

Post by *petermad » 2006-03-05, 21:05 UTC

2Lefteous

It's currently impossible to reuse the unpack protection password for repacking.

May I ask why you had to change the behaviour for SOLID archives in 1.07beta3. The previous beta2 seemed to work OK for solid files simply re-using the password for the archive when repacking, without asking any questions?

It was only with non solid archives there was a problem with keeping the password!

Now these two new dialogs when repacking - they are not very user-friendly IMHO.

Post by *petermad » 2006-03-05, 21:10 UTC

How large is the archive you have used for testing?

18941 bytes containing 3 ansi text files.

Post by *petermad » 2006-03-05, 21:28 UTC

2Lefteous
Another question: What is the rationale behind the sort order of the archived files?

If I view a SQX archive unsorted I can see that the files are grouped, but not exactly sorted, according to extension - .ini comes before .exe that again comes before .dll.

I cannot find the pattern of the sorting - but it is certainly not the same order as the unsorted disk order (on FAT partions).

Lefteous · Post by *Lefteous » 2006-03-05, 21:54 UTC

2petermad

May I ask why you have changed the behaviour for SOLID archives in 1.07beta3. the previous beta2 seemed to work OK for solid files simply re-using the password for the archive when repacking, without asking any questions.

As you have already quoted the change log....
In the prevoius version I cached the unpack password. This caused problems with non-solid archives I you know. Maybe I can change this later but not now.

It was only for non solid archives there was a problem with keeping the password?

Maybe I have to explain a bit about non-solid archives here. Non-solid archives don't have a single unpack single password necessarily. Each file could have an individual password. That's why the new password dialog has two input fields. If the user entered just one password and makes a typo he will never be able to unpack the archive again.

Now these two new dialogs when repacking - they are not very user-friendly IMHO.

Well the award-winning ("excellent operator guidence") application SpeedCommander does it the same way.
It may have worked for you in the previous beta. But actually it didn't.

My current effort is to kill as many bugs as possible. This is priority one.

Lefteous · Post by *Lefteous » 2006-03-05, 21:59 UTC

2petermad

18941 bytes containing 3 ansi text files.

That's not really large. A long unpack delay should not be the problem.

Another question: What is the rationale behind the sort order of the archived files?

All I know is the files are grouped by file type in solid archives.

If I view a SQX archive unsorted I can see that the files are grouped, but not exactly sorted, according to extension - .ini comes before .exe that again comes before .dll.

Sounds interesting I have never tried this before.

I cannot find the pattern of the sorting - but it is certainly not the same order as the unsorted disk order (on
FAT partions).

SQX tries to group similar file types together to increase compression ratio.

Thanks for all your tests.
I should hurry up with developing Total SQX as long as other beta tests haven't started...

I'm currently investigating the other bug your reported.

Lefteous · Post by *Lefteous » 2006-03-05, 22:29 UTC

2petermad

This directory is NOT deleted by the plugin after the repacking. This leaves all the other files, that might have been in the archive

I could reproduce this. The problem seems to be that if the files to be extracted are at the beginning of the archive all other file are also extracted.
This is caused by an optimization I introduced in Total SQX 1.02. All files are extracted in one go. The problem here is that the plug-in gets no information that the other files other files shouldn't be extracted.

Lefteous · Post by *Lefteous » 2006-03-06, 09:11 UTC

2ghisler(author)
Is there any chance TC will call ProcessFile with operation set to PK_SKIP even if there is no file to extract behind an extracted file?

Example archive listing:
File001.bmp
File002.bmp
File003.bmp

Files to be extracted:
File001.bmp
File002.bmp

TC ProcessFile calls:
ProcessFile (PK_EXTRACT; File001.bmp)
ProcessFile (PK_EXTRACT; File002.bmp)

Expected ProcessFile calls:
ProcessFile (PK_EXTRACT; File001.bmp)
ProcessFile (PK_EXTRACT; File002.bmp)
ProcessFile (PK_SKIP)

Background:
Total SQX has a special unpack mode which unpacks archives which many files much faster when PK_SKIP is never called while extracting. The problem is in this case that "unpack all"-mode is used in this case although it shouldn't.

Sven · Post by *Sven » 2006-03-06, 10:48 UTC

Lefteous wrote:2petermad
Well the award-winning ("excellent operator guidence") application SpeedCommander does it the same way.

Not exactly. SC only asks for the unpack password (which is needed for extracting the solid archive). Afterwards this password is used again for compression.

Lefteous · Post by *Lefteous » 2006-03-06, 11:11 UTC

2Sven

Not exactly. SC only asks for the unpack password (which is needed for extracting the solid archive). Afterwards this password is used again for compression.

For me it looks like this:

1. Doubleclick archive
2. Select file to edit
3. SC asks for password.
4. File is displayed in Notepad. User edits, saves and closes the file.
5. SC asks asks for updating the archive. User answers yes.
6. Compression assistent --> User presses finish button
7. SC asks for the unpack password again.

Each time I unpack a file in the archive SC asks me again for the password - even if I attempt to open the same file twice.

Sven · Post by *Sven » 2006-03-06, 11:36 UTC

You are right. Only the password for the archive directory is cached.

But I don't understand why:

It's currently impossible to reuse the unpack protection password for repacking.

Lefteous · Post by *Lefteous » 2006-03-06, 11:52 UTC

2Sven

But I don't understand why:
It's currently impossible to reuse the unpack protection password for repacking.

Because I delete the unpack password after each extract operation.

Sven · Post by *Sven » 2006-03-06, 12:06 UTC

Ah, ok. I read: "If the file is protected with password '123' it is impossible to repack the file with password '123'."

It is possible to add the file name to the password dialog the password is requested for?