I really liked the way WAU handled this, by deleting the folders to the trashcan prior to updating. I'm still in the habit of clearing the trashcan, updating, and then if something goes awry, I can easily restore from there.
Here's the problem.. WAU is a windows-only app, therefore, it can always be assumed there will BE a recycle bin..
jWU is a cross-platform updater.. Which means that not only can you NOT assume there's a recycle bin, but even if there is, the chances of it working the same across 30 different linux distros, mac -and- windows are less than .01% - so its not really a workable solution.
Well since the files are empty, they will only take up space in your file allocation table, hence they wont be a source of fragmentation :)
Unless of course, you aren't using NTFS or FAT. Ext2/3 filesystems use a different type of allocation, and the HFS+ fs in Mac OS X also.. If the file exists, it uses at least 1 block. Each partition has a set number of available blocks. Similar to filesystem sectors in FAT/NTFS. Which, basically means: a size-zero file has an actual on-disk size equal to the size of the blocksize of the FS. Now, that aside, I know that some modern filesystems can actually do block compression, where files that dont quite take up all of their last block can actually begin the next file in the same block.
My HFS+ filesystem uses 512byte blocks, or 0.5k. Which means that any zero size file actually claims 512bytes of HD space. :)
Only problem is how you would ask for the changelog for an addon, and how you would then say not to update a certain update.
Im not sure i would like to break the easy 1 button updating that is present atm.
And also if JWU is to download the changelog for each avaliable addon, it would take alot longer to update the addon lists.
Ill give it a think over.
Make a subroutine, in the main updater routine, add a check for whether or not the user has selected to view changelogs beforehand or not. Problem 1 is solved. As for problem two, My best suggestion is to use the same system you used in the non-ace updater code, whereby you flag certain addons to be downloaded. If the user doesnt care about the "beforehand" knowledge of the changelogs, simply autoflag -all- addons to be updated.
Personally, I would never use this option. Just giving you coding ideas about implementation should you decide to add the feature.
Im not sure that this would be possible, unless the changelog is located somewhere else beyond the .zip file. As i need to download and unpack that to get to the file, it might aswell install the update aswell.
Unfortunatelt, this means it might install, for instance, ParserLib, Parser-3.0, -and- LibParser-4.0. However LibParser4 how "compatibility layers" that allow it to work in place of the other two. GratuityLib + LibGratuity do the same. As does Abacus, Crayon, and Tourist.
- Only scan for non ace addons once during a normal update run.
- Importing an xml package that contains a non ace addon, will not make the non ace addon show up more than once.
- Should detect and handle adds on Curse.com
Whoops.. you got the non-ace thing backwards.. it scans for the addons at launch.. and never actually updates them.
Only one thing is missing now, rolfba.. svn support :)
updating svn addons should be made automatic.. if the updater detects a .svn folder, then just run the external command "svn up" on the folder name. if use-nonexternals is selected, then run "svn up --ignore-externals" on the folder name.
Simple, yet effective. :)
If the user doesn't have svn in their path, then simply mention that the first time it sees a .svn folder in the addon's folder heirarchy.
Hm, is there a way in JWowUpdater to ignore not installed addons? Like I don't want it to install Parser-1.1 and Parser-3.0 as I already have LibParser-4.0, and like some other libraries, it has a compatible layer to older versions. In the Addon IgnoreList I can only select installed mods.
2 different work-arounds.. after jwow has installed those addons, you can then set them to ignore, and delete the .tocs
create the folder(s) for the addons you dont want it to autoinstall, then create a .svn folder inside them.. jwow will ignore them, and will not auto-install those libs.
roflba, I've fuddled around with applescript to try and move said files into the application bundle.. its not easy, and the only solution I can come up with is an -awfullly- kludgy combination of bash-script and applescript, and it's likely to fail in a lot of circumstances..
My only other idea is, simply redistribute the zip I posted, and dont bother updating it, and just tell the mac users to be sure to let it auto-update (which works fine).
This is how many major software companies do things. You buy a CD/DVD, get it home, install it, and the first time you run it, it downloads updates..