Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
No, not Plugin Archiver. It has a hyphen.
Introducing: Plug-in Archiver version 1.0.7... ...with direct resource fork streaming, icon file exclusion, and a spiffy new logo!
Plug-in Archiver version 1.0.7 has unprecedented processing times for an application with its name (including the hyphen; I make no claims in regards to that silly little script).
Special deal: if you download Plug-in Archiver between now and infinity, you get it free *!!!
Mac OS X only. Download Plug-in Archiverhere. (You must have OS X 10.3 or a recent version of StuffIt to expand the archive. ZP, get over it.)
N.B. This is a preview version of Plug-in Archiver; it therefore contains no ReadMe. Once I am sure it is ready to be released and show just how much difference a hyphen makes, I will add one and submit it to the Add-ons Page.
*While bandwidth lasts.
EDIT: Download links help.
This post has been edited by orcaloverbri9 : 07 October 2006 - 11:16 PM
Ooh, it is faster! However it's still a silly little RB app and now has as much progress indication as a silly little script :p. I have the source code to a nice little archiving app (real universal cocoa app!) which someday I planned to convert to a plugin archiving app with a few preferences and stuff, though sadly still no progress indication (although I did find out how to have preferences in an applescript).
Major bugs: - Codes are lost!
Minor issues: - Existing archive with same name is deleted without warning - Temp archive is visible - No progress indication is available during processing but afterwards the window reads... Click on one of the above buttons to Writing encoded file...
(edit) btw, on a sorta related note which I was just reminded of while checking this out, Expander 10 freezes for me when I try to extract any bin zip file. Anyone else have this problem? This really sucks because it used to be able to extract the bin files at the same time so that you'd never see them but now there is no program that can do this.
This post has been edited by Guy : 08 October 2006 - 12:18 AM
Codes? As in, creator/type?
The "Writing encoded file..." is an accident. I removed all the status changes when I added resource fork streaming because it for some reason caused them not to update. Apparently I missed one.
And, temp archive? As in, the .zip archive? That's the fault of whatever command-line app it uses. I guess I could have it zip into the temp folder and then move it...
Yeah, the creator/type codes. If you're already creating an invisible temp folder then yes, I think it would be good to create the zip archive inside that folder.
Okay, pushing it a little now - Data fork may not get properly preserved (try archiving the Nova app). This is an outstanding issue from previous versions of your app. - It seems bin doesn't support long file names yet the resulting .bin file from your program retains the complete original name. This means when you decode the bin-file-with-a-really-long-name it ends up with a shorter name. This isn't really an issue at all I guess but just thought I'd note it anyway. - Can't handle funny characters (also '/'). "Zip command failed with error code 3072" - NilObjectException if no read access to some of the files - Does nothing if only one file with no resource fork - NilObjectException if you click cancel when it asks where to save (which happens if it can't automatically save to either source or desktop) - Again in above situation if there's only one file the default name displayed will end with ".bin" (regardless of whether or not the file has actually been encoded) so when you click Save it complains that the required extension is ".zip". - If only one file by drag-n-drop there's a dialog that flashes up for a split second after processing which I managed to capture. It reads... An error occurred while attempting to process the file " <filename.bin>": Unable to create zip file () This strange because it actually gets zipped fine.
This post has been edited by Guy : 08 October 2006 - 03:33 AM
Excellent news!
@orcaloverbri9, on Oct 8 2006, 06:14 AM, said in The Return of Plug-in Archiver:
(You must have OS X 10.3 or a recent version of StuffIt to expand the archive. ZP, get over it.)
Heh. Guess I've been complaining a bit too loudly about some things. But this is not a problem at all here because: - this thing is targeted as plug(-)in developers (not plug-in users), who I hope got a recent version of Stuffit Expander if they are still running 10.2 (which make me think that a new, Universal version of Stuffit has been released recently, no problem so far) - it's obviously useless for a Windows guy to be able to obtain this - and anyway, this tool is most useful to compensate for versions of Stuffit which do not provide this feature anymore, but these are 10.3+ only.
I'll test this more thoroughly later.
@guy, on Oct 8 2006, 02:39 AM, said in The Return of Plug-in Archiver:
- Data fork may not get properly preserved (try archiving the Nova app). This is an outstanding issue from previous versions of your app.
Hmm...indeed, the expanded version seems to be smaller. I'll check this out, although it's probably the fault of RB.
Quote
- It seems bin doesn't support long file names yet the resulting .bin file from your program retains the complete original name. This means when you decode the bin-file-with-a-really-long-name it ends up with a shorter name. This isn't really an issue at all I guess but just thought I'd note it anyway.
Meh, fine. I'll see what I can do.
Can't handle funny characters (also '/'). "Zip command failed with error code 3072"
Go blame the guys who wrote zip.
NilObjectException if no read access to some of the files
Hrmm.
Does nothing if only one file with no resource fork
???
It's supposed to just copy them...
NilObjectException if you click cancel when it asks where to save (which happens if it can't automatically save to either source or desktop)
I probably know what's wrong there, but I seem to recall those methods being quite complex to avoid any of these problems. Crap.
Again in above situation if there's only one file the default name displayed will end with ".bin" (regardless of whether or not the file has actually been encoded) so when you click Save it complains that the required extension is ".zip".
Agh. You don't have the third option in the prefs selected with <src>.bin, do you?
If only one file by drag-n-drop there's a dialog that flashes up for a split second after processing which I managed to capture. It reads... An error occurred while attempting to process the file " <filename.bin>": Unable to create zip file () This strange because it actually gets zipped fine.
Probably bad if arrangement. I was getting errors for every file because of this yesterday.
This post has been edited by orcaloverbri9 : 08 October 2006 - 12:33 PM
@orcaloverbri9, on Oct 9 2006, 02:55 AM, said in The Return of Plug-in Archiver:
The zip command line tool? You should put all your paths in quotes.
Nope.
Just a suggestion - seeing as there's no progress indication anymore (probably due to the program seemingly locking up when processing) perhaps you can make the window say that it's doing something before it actually begins. And maybe disable the buttons too, just for, erm, some reason.
@guy, on Oct 8 2006, 05:51 PM, said in The Return of Plug-in Archiver:
I'm pretty sure they are all in quotes. EDIT: A quick check confirms the use of quotes.
Hmm... EDIT: Found the error...should be fixed now.
Well, due to the structure of the program, I had difficulty doing this. Just before compiling, I tried adding a progress wheel (the spinny thing that's fun to watch), but because of the way I've written it (which does, of course, make it my fault, but nonetheless I'm not about to rewrite it), it's quite a task. Perhaps in .8.
This post has been edited by orcaloverbri9 : 10 October 2006 - 06:59 AM
@orcaloverbri9, on Oct 10 2006, 11:55 PM, said in The Return of Plug-in Archiver:
Well my script handles them fine. Here's the method I use, though I'm sure it's of little use to you:
on GetPath(AnItem) return quoted form of POSIX path of (AnItem as alias) end GetPath
Oh yeah, that spinny thing would be cool
This post has been edited by Guy : 10 October 2006 - 03:47 PM
Oh crap.
Plug-in Archiver works as far as I can tell. However there seems to be a bug in Stuffit 11 which prevents (some) .bin.zip archives from being expanded: Expander just sits there (probably deadlocked in its worker decompressing thread) with the progress bar empty, "stop" simply replaces the empty bar by a barber pole, but it remains stuck, I have to force quit it. I only notice it now since it only happens when it is set to further expand uncompressed files (which is unset for me most of the time, as I have to do analysis of archives produced by others and of course this util), there is no problem when fist expanding the .zip, then the .bins separately. This is with the Intel version of course (this 11 version is the first to be universal), this bug might not show up on ppc Macs. Some .bin.zip archives come out fine (Spaceball, for instance), while others don't. I'll have to investigate this some more, before filing a bug report to Allume (grr....)
Yeah, I noticed that too. Very annoying.
I've considered writing a Cocoa port of it, and Plug-in Archiver uses a lot of Cocoa/Carbon functions anyway - to mention all the work I've done to make it feel as much like a Cocoa app as possible.
Thankyou both for finally confirming what I said in my first post <_<. Okay, so I mistakenly wrote 10 instead of 11 but still, how come no one answered?
The UB beta of Expander 10 worked fine, just for the record.
This post has been edited by Guy : 15 October 2006 - 06:02 PM
Well, because you mistakenly said 10 instead of 11, that's why. Honest, I only found out about 11 a little after your initial post and did not make the connection then, so I did not try and reproduce the bug with the new version.
UB Beta of Expander 10?! Gah! iWant! But I suppose it's no longer available...
Let's hope a minor update will fix the bug soon...
You missed that? It was publicly available. I foolishly threw it away after upgrading but I think it expired end of October or something like that. So yeah, report it and we can hope for an update
@zacha-pedro, on Oct 16 2006, 02:00 PM, said in The Return of Plug-in Archiver:
Well, because you mistakenly said 10 instead of 11, that's why.
Indeed, that's why.
Plug-in Archiver update on the horizon. Let me see if I can stream the data fork like the resource fork - hopefully it would help with the data fork shrinking issue.
I further nailed down the problem. It does not depend on the zipping or binning tools used (it happens as well when binning and zipping by hand with MacBin Drop and Zippist), it happens also with ppc Expander 11 (or at least Expander 11 when launched under Rosetta on my MacBook); I ended up realising it was dependant on the size of the file(s) that are binned, and after some more tries (and the deflation percent indicator of Zippist) I finally found out that the problem happened if, and only if, the size of the .bin file (or of at least one .bin file, if more than one) once compressed inside the .zip is more than 64kB (which makes me suspect some sort of 16-bit limitation bug somewhere deep within the decoding engine, in the case it's set to "continue to expand if possible"). I uploaded two files, Test1 and Test2. One does decompress fine, the other doesn't, the only difference is that the "Untitled" file inside the second is slightly smaller (the data I put in Untitled comes from the middle of a compressed file, so that it would not be significantly compressed when zipped, it's quite hard and time-consuming to write data that will take up significant space once compressed, you can not just type on your keyboard at random then copy-paste, it will be well compressed). Notice it is not of any importance whatsoever whether the size of the .bin file comes from its data or resource fork or both, just as long as it takes more than 64k once compressed, the bug happens. That's why it didn't happen with spaceball, it's so small it didn't trigger the bug.
By the way Orca, I noticed you don't store the creation and modification date in the .bin files you produce. You might wish to consider doing so.
This post has been edited by Zacha Pedro : 22 October 2006 - 05:00 AM
@zacha-pedro, on Oct 21 2006, 03:26 PM, said in The Return of Plug-in Archiver:
?
Weren't you the one who said not to worry about it?
Anyhow, I can. Now that the bug has been fixed that was preventing me from doing it originally, it will be easy.
I ever said that ?! Perhaps I did, but then it was only for an initial version, a well-behaved MacBinary encoder should definitely store this kind of data.
EDIT: Got an answer from SmithMicro's technical support about the issue, it is already being adressed and will be fixed in the next minor update.
This post has been edited by Zacha Pedro : 23 October 2006 - 12:30 PM
Good to hear