Altap Salamander Support Forums

I recently started using PAK archiving for some of my data and today I noticed problem when trying to pack what seems to me ordinary files.

I got this error: Can't add file because of too long name

As error happened for the third time today I thought of reporting.
File path isn't too long. It's 176 chars in this last case but that ain't much. Also there are no problems if I use other archivers like ZIP, so perhaps something could be wrong with PAK archiver

PAK doesn't look to store a path.

http://en.wikipedia.org/wiki/PAK_(file_format)

I can "successfully*" create a PAK "archive" at a filepath length of 184 characters.
*internally the archive shows: "finish operation because of too long name", so I suspect something is not right.

I cannot create a PAK archive at a filename length of 105 characters.
Popup error must be from the plugin.

So looks like there is a filename length maximum.

Thinking it must be ~57 characters?
And at 57 characters, looks like it truncates the last byte, making the archive invalid.
Not sure where things actually work? Seems to be highly buggy.


([strike]Except for "games",[/strike] I really fail to see the reason for PAK's existence?)


What are you using PAK for?

55 character filename (including .ext) looks to be the maximum length before error of some sort start to occur.

Path (length) does not seem to be an issue - unless you're archiving subdirectories too.
And in that case, the 55 character maximum length is looking to be subdirectory+name length or something like that.


(I see absolutely no use for anything so worthless.)

therube wrote:So looks like there is a filename length maximum.

Thinking it must be ~57 characters?
And at 57 characters, looks like it truncates the last byte, making the archive invalid.
Not sure where things actually work? Seems to be highly buggy.

Thanks, I should have done more checking, but was busy with other things
Filename length seems like problem

therube wrote: ([strike]Except for "games",[/strike] I really fail to see the reason for PAK's existence?)
What are you using PAK for?

It packs in second and it's not ZIP

using PAK archiving for some of my data

If you really are using this for something of importance, I would look elsewhere.
The simple fact that there looks to be no validation of any type ... before, during, or after ...

therube wrote:If you really are using this for something of importance, I would look elsewhere.
The simple fact that there looks to be no validation of any type ... before, during, or after ...

OK, I'll reconsider this, but I already have things packed in this format

It pack in second and it's not ZIP

And that is what is does, it "packs". It does not compress.
You can have other archivers set to "pack", not compress too.

TAR is a Tape ARiver, no compression.
Often it is used with gzip, to supply the compression.

ARJ has a switch -M0, which says to use no compression, so it acts as a "packer".
Making it very fast, as it does not compress. And still is very robust.

Imagine that ZIP or RAR or 7z too should offer similar.

OK, I'll reconsider this, but I already have things packed in this format

I would unpack & verify your data & then use something else.
Believe you will find that any number of your archives are corrupt.

Well I want to pack as fast as possible. Packed files are usually already compressed (setup files, PDF, audio...) so I never use compression on anything unless it's some text file, when I use 7z PPMd.
I think I'll repack in 7z again
Thanks for your replies

Well I want to pack as fast as possible.

Understandable.

Packed files are usually already compressed (setup files, PDF, audio...)

True.
Makes no sense in "compressing" in those circumstances.

So use a robust archiver, & set it to "store" rather then compress.

I see RAR can store too, -m0, set compression level (0-store).
And 7zip must have that option available also.

I'll go with 7z after this conversation
I used stored ZIP, but PAK seemed faster than any archiver I used (i.e. with thousands files and subfolders), that's why I went with with it

i.e. with thousands files and subfolders

Oy. Or should that be ouch.

Might find these interesting?
This is a bit dated, might say ancient, but during it's time it was the place: Archive Comparison Test. Had never heard of this one: Compression Ratings.

Oh, & do test your archives after creating them.

I ended using ZIP. It's a lot faster then 7z (both set to store)

I'm glad I posted this PAK issue, as I really wasn't aware how awful this format is. Thanks to therube for suggesting switch to other format

I had hard time to find CLI unPAK, as AS can't unpack multiple archives and 7z somehow doesn't recognize majority of PAK archives

1. winpak can't handle more than one archive - no CLI, can't batch
2. found java unpak, but it didn't recognize this format
3. I remember Necromancer DN had archives pack on their download page and downloaded it. PAK archiver throw errors probably because it wasn't meant for NT and it can't handle LFN Various other archiver didn't help
4. I tried IZArc and IZArce (CLI addon) - no way, uninstall (program didn't unregister it context menu addons, nor cleaned it reg garbage)
5. WinAce can't recognize, although their free xace can extract fine, but no option for multiple archives at one pass (main problem)
6. WinUHA - no way
7. Finally I found Game Archive UnPacker for TC and finished in TC with one click

Never using PAK again