Instead of using an empty file "noext" to detect if an addon is installed with or without extarnals just assume all addons are installed with whatever the "No externals" setting is set at. When the user change the setting show a popup that he'll have to use "Reinstall addons" for the change to have full effect.
Instead of using an empty file "version-#####.#" to know what version an addon is at you could get that information by parsing the filename of Changelog-<Addon name>-r#####.txt or make a list and save it wherever JWU saves its settings.
The point is to not clutter the folder of the addon with files that's not actually from the addon.
I read in your changelog somewhere about GIT support in areas but I don't exactly know what this means. Is it possible to grab from someones git repo now? or has it been added for some other reason? I have a LOT of addons that are really only available on gits, which means they don't get updated by this updater. If it would be possible to provide the link to the addon on that git just like you handle other addons sites that would be amazing.
The point is to not clutter the folder of the addon with files that's not actually from the addon.
I suggested exactly the same thing some time ago; I don't remember the exact reasoning he responded with, but for some reason rolfba is really attached to those cluttery little things. :P
Instead of using an empty file "noext" to detect if an addon is installed with or without extarnals just assume all addons are installed with whatever the "No externals" setting is set at. When the user change the setting show a popup that he'll have to use "Reinstall addons" for the change to have full effect.
Instead of using an empty file "version-#####.#" to know what version an addon is at you could get that information by parsing the filename of Changelog-<Addon name>-r#####.txt or make a list and save it wherever JWU saves its settings.
The point is to not clutter the folder of the addon with files that's not actually from the addon.
Well the short answer is, im really satisfied with how its working now, and i cant see how around 3 files in an addon directory can possibly be clutter.
I dont want to start changing things like this when its working as intended.
I read in your changelog somewhere about GIT support in areas but I don't exactly know what this means. Is it possible to grab from someones git repo now? or has it been added for some other reason? I have a LOT of addons that are really only available on gits, which means they don't get updated by this updater. If it would be possible to provide the link to the addon on that git just like you handle other addons sites that would be amazing.
I wont be including support for git anytime soon, as i dont want to start creating processes calling out to other executables.
Well the short answer is, im really satisfied with how its working now, and i cant see how around 3 files in an addon directory can possibly be clutter.
Haha. If it were one directory, it wouldn't really be clutter... but when you have some 300 folders in your addon directory, each with 3 files, that's 900 empty junk files. They don't see to occupy any disk space, but I'm sure they're contributing to disk fragmentation in addition to being visually annoying when visiting the addons folder. :P
Haha. If it were one directory, it wouldn't really be clutter... but when you have some 300 folders in your addon directory, each with 3 files, that's 900 empty junk files. They don't see to occupy any disk space, but I'm sure they're contributing to disk fragmentation in addition to being visually annoying when visiting the addons folder. :P
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 :)
Also i think its nice when browsing an addon directory, to quickly be able to say, ahh this addon is installed as No extensions, and has been split.
Regarding the version file, im using it to record the "library" versions that get released. This dosent show from the changelog, since the addon didnt actually change. So the version-x.y file will tell JWU the lib version y, if present.
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. :)
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. :)
Yes, but in filesystems like NTFS, small files are saved directly in the master file table, which is already allocated, so it wont take up any "real" diskspace, just some of the MFT space :)
And 300 addons, with 3 files, 0.5kb each is an astonishing 450kb used diskspace! =)
Also i think its nice when browsing an addon directory, to quickly be able to say, ahh this addon is installed as No extensions, and has been split.
Well, if there was a way to set some addons to download without externals, and others with externals, this might make sense, but since the settings are global, not so much.
Regarding the version file, im using it to record the "library" versions that get released. This dosent show from the changelog, since the addon didnt actually change. So the version-x.y file will tell JWU the lib version y, if present.
This does make more sense... but for no-ext users, also irrelevant since we don't actually download lib updates. And as Snago mentioned, all of these things could easily be stored in JWU's config file.
Anyway, the actual reason I came to the thread was to ask if it would be possible to show the date of the last new revision as opposed to the date of the last new zip in the "install new addons" list... or at least show the revision instead of (or in addition to) the date. With all the library update repacks, it's impossible to tell if an addon has actually been updated for the 2.4 patch without downloading it and checking the revision number, because the date column only lists the date of the last zip.
Is there a way to rollback once you've updated with JWU? It didn't recognize some protections I had on breakable addons and it's completely hooped my ui.
Is there a way to rollback once you've updated with JWU? It didn't recognize some protections I had on breakable addons and it's completely hooped my ui.
No im affraid you cant roll back an update.
For further references, JWU wont update an addon if you have a .svn or .git folder inside, or you could simply add the addon to the Ignore list.
I am getting the following error in Windows Vista x64, with UAC enabled.
******** Checking if split addons need updating ********
******* Starting SplitUpdate *******
LibPeriodicTable-3.1 was external version, but no-ext flag is set. Scheduling for update.
Name: LibPeriodicTable-3.1 Your Version: 69349.0, Latest: 69349.0 (Out of date)
Updating....Error: java.io.FileNotFoundException: C:\Program Files (x86)\World of Warcraft\Interface\AddOns\LibPeriodicTable-3.1\pt3lod.bat (Access is denied)
This error causes a never-ending loop (JWU keeps trying again and spitting out this same error).
I think the issue is that JWU is trying to execute the .BAT file at the wrong location? It should be the following for Vista users with UAC I think:
C:\Users\Username\AppData\Local\VirtualStore\Program Files (x86)\World of Warcraft\Interface\AddOns
Also, it might be helpful to have a way of stopping infinite loops so users can look at the error messages easily.
If I'm doing something wrong, please let me know. Thanks!
First - Love the application. Big fan of Java and was thrilled when I found this. The proxy settings allow me to use it at my university. About that, any chance that the proxy password not be displayed in plain text? Im pretty much the only person that uses my machine but rather safe than sorry.
Also, when I unmaximize the window when update is in process I get alot of overlapping test. Not huge problem, just cosmetic.
Thanks for the great program. Much better than WoWAceUpdater.
JWU dosent execute any .bat files at all, so im a little lost as to why this error comes up at all.
Could you upload your JWowUpdater.log somewhere i can read it. (After running JWU and getting this error)
/Rolf
I've attached my jwowupdater.log to this post. I'm not sure if you can gleam anything useful from it. As far as I can tell, it's just trying to update/install LibPeriodicTable-3.1.
P.S. It says
Succesfully deleted: [C:\Program Files (x86)\World of Warcraft\Interface\AddOns\LibPeriodicTable-3.1]
but I don't believe that's true. My AddOns reside in
C:\Users\Username\AppData\Local\VirtualStore\Program Files (x86)\World of Warcraft\Interface\AddOns
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.
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.
break19
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Instead of using an empty file "noext" to detect if an addon is installed with or without extarnals just assume all addons are installed with whatever the "No externals" setting is set at. When the user change the setting show a popup that he'll have to use "Reinstall addons" for the change to have full effect.
Instead of using an empty file "version-#####.#" to know what version an addon is at you could get that information by parsing the filename of Changelog-<Addon name>-r#####.txt or make a list and save it wherever JWU saves its settings.
The point is to not clutter the folder of the addon with files that's not actually from the addon.
I suggested exactly the same thing some time ago; I don't remember the exact reasoning he responded with, but for some reason rolfba is really attached to those cluttery little things. :P
Well the short answer is, im really satisfied with how its working now, and i cant see how around 3 files in an addon directory can possibly be clutter.
I dont want to start changing things like this when its working as intended.
/Rolf
I wont be including support for git anytime soon, as i dont want to start creating processes calling out to other executables.
/Rolf
Haha. If it were one directory, it wouldn't really be clutter... but when you have some 300 folders in your addon directory, each with 3 files, that's 900 empty junk files. They don't see to occupy any disk space, but I'm sure they're contributing to disk fragmentation in addition to being visually annoying when visiting the addons folder. :P
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 :)
Also i think its nice when browsing an addon directory, to quickly be able to say, ahh this addon is installed as No extensions, and has been split.
Regarding the version file, im using it to record the "library" versions that get released. This dosent show from the changelog, since the addon didnt actually change. So the version-x.y file will tell JWU the lib version y, if present.
/Rolf
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. :)
Yes, but in filesystems like NTFS, small files are saved directly in the master file table, which is already allocated, so it wont take up any "real" diskspace, just some of the MFT space :)
And 300 addons, with 3 files, 0.5kb each is an astonishing 450kb used diskspace! =)
/Rolf
Well, if there was a way to set some addons to download without externals, and others with externals, this might make sense, but since the settings are global, not so much.
This does make more sense... but for no-ext users, also irrelevant since we don't actually download lib updates. And as Snago mentioned, all of these things could easily be stored in JWU's config file.
Anyway, the actual reason I came to the thread was to ask if it would be possible to show the date of the last new revision as opposed to the date of the last new zip in the "install new addons" list... or at least show the revision instead of (or in addition to) the date. With all the library update repacks, it's impossible to tell if an addon has actually been updated for the 2.4 patch without downloading it and checking the revision number, because the date column only lists the date of the last zip.
Thanks!
No im affraid you cant roll back an update.
For further references, JWU wont update an addon if you have a .svn or .git folder inside, or you could simply add the addon to the Ignore list.
Im sorry if this has given you some problems.
/Rolf
This error causes a never-ending loop (JWU keeps trying again and spitting out this same error).
I think the issue is that JWU is trying to execute the .BAT file at the wrong location? It should be the following for Vista users with UAC I think:
Also, it might be helpful to have a way of stopping infinite loops so users can look at the error messages easily.
If I'm doing something wrong, please let me know. Thanks!
http://www.wowace.com/forums/index.php?topic=12103.0
JWU dosent execute any .bat files at all, so im a little lost as to why this error comes up at all.
Could you upload your JWowUpdater.log somewhere i can read it. (After running JWU and getting this error)
/Rolf
Also, when I unmaximize the window when update is in process I get alot of overlapping test. Not huge problem, just cosmetic.
Thanks for the great program. Much better than WoWAceUpdater.
/Robert
I've attached my jwowupdater.log to this post. I'm not sure if you can gleam anything useful from it. As far as I can tell, it's just trying to update/install LibPeriodicTable-3.1.
P.S. It says
but I don't believe that's true. My AddOns reside in
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.
break19