Jason Bassford wrote: >>The value of "archive" holds the full path to the temporary location >>But how to I get JUST the value of the folder? (I need to strip out > > I figured this one out too: > > archiveDir = dirGetParent(archive);
Oh right, forgot that's where it moved. That syntax is deprecated, use File.dirGetParent() instead or your scripts will one day stop working (by 1.2 most likely, whenever we've got time -- didn't want to make the change prior to 1.0) How did you find that one? only File.dirGetParent is documented. http://www.mozilla.org/projects/xpinstall/ The distinction is that commands on the Install. object operate on items inside the archive, methods on the File object refer to files on disk (or are abstract manipulations). > However, now I've discovered something even MORE annoying. APIs are > not actually decompressed to the file system - they're only stored in > memory. I don't know what this means. Do you use API to mean file? http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=API Install transactions (the commands between initInstall and performInstall) are not performed until you say performInstall() if that's what you mean. That allows script authors to undo everything if there's a problem by using the cancelInstall() command. That's why I mentioned the possible need for multiple transactions. > Now that I've determined what directory the API is in, and also how to > execute an external command, how the hell do I do something as simple > as copying a file contained in the API to somewhere else? addFile() and addDirectory() are used to get files out of the .xpi archive and placed on disk. > Don't tell me I need to execute an "unzip" command to get the API > decompressed to the file system, execute an external copy command, > then delete the just unzipped files? If you're not installing the files but instead using them for something temporarily then yes, you'll have to delete them when you're done. > I can't believe that this is so complex. Why doesn't Mozilla have > built-in support for .jar file handling? It's complex because you're trying to do something that not only have we not needed to do, the chrome folks fairly explicitly want you NOT to do. Why waste time implementing features we don't need? Zip writing code is much more complex than zip reading code, and up to now nothing in Mozilla has needed zip writing code. A shipped .jar is a binary unit, conceptually just like one of the binary libraries: tested and created as a whole. The approved method for altering chrome on the fly is external overlays. If you want to ship a different comm.jar that's 99% the same then go ahead, but then it's your product. Trying to modify one the user has is just a bad idea. Sure, if you're the only guy in the world doing it it'll probably work. But once the floodgates open it won't be just you. Everyone will make their changes assuming an unchanged comm.jar and pretty soon you've got a conflicting, unworkable mess. > It would be *SO* much > simpler if I could just have a basic one liner to copy files in the > XPI into an existing Mozilla .jar... I'm not against built-in full-featured zip archiving support, but code doesn't write itself and so far no one has wanted it enough to pony up the code or the cash. -Dan Veditz
