As you can see, the Buff, Focus, Range, Swing, and Timer subfolders have been deleted, even though they were specified in Remove.conf as \Quartz_* rather than \Quartz\*. That's why I think it may be re-packaging after updates.
Can't reproduce that, it's working perfectly here.
Same with the first bug you mentioned, about not handling packages while updating but working properly when installing. I've tested it with a few packages, double checked the code and, from what I can see, it's fine. Actually, the update and install use the same function to install the addon so there really shouldn't be any problems with it...
According to the log file, everything's working fine, can't really figure out what's really happening on your side, sorry :(
As you can see, the Buff, Focus, Range, Swing, and Timer subfolders have been deleted, even though they were specified in Remove.conf as \Quartz_* rather than \Quartz\*. That's why I think it may be re-packaging after updates.
Can't reproduce that, it's working perfectly here.
Same with the first bug you mentioned, about not handling packages while updating but working properly when installing. I've tested it with a few packages, double checked the code and, from what I can see, it's fine. Actually, the update and install use the same function to install the addon so there really shouldn't be any problems with it...
According to the log file, everything's working fine, can't really figure out what's really happening on your side, sorry :(
Oh well, it's not a huge deal. Thank you for trying, and I'm sorry I couldn't be more helpful in debugging. >_<
Edit: I went through the code one last time, and the only thing I could find that could be causing my problem is this line in FileSystem.HandlePackage():
According to MSDN, Directory.Move() will fail if the new directory already exists (which would be the case when updating a packaged addon without DeleteBeforeExtracting, as I do). That might explain why you're not having the problem. It still doesn't explain why Remove.conf magically knows where the module subfolders are, though... o.O
Directory.Move errors were a common problem for WAU.
I know i have had to add several Directory.Exists() checks. I havent seen your code though, you may do stuff differently.
EDIT Looking at the code, (just a guess), but the program probably deletes the files in remove.conf, but for some reason doesnt delete the existing module folders when updating them, so only those modules which you have set to delete get moved from the addon's directory (then they are deleted by remove.conf)
WAU moves the directories into and out of the main addon every time it updates, but that is more to allow for recursion. I'm not really sure how your code could work (for packages) without delete before extract on, but i only looked at it for a couple minutes.
Looking at the code, (just a guess), but the program probably deletes the files in remove.conf, but for some reason doesnt delete the existing module folders, so only those modules which you have set to delete get moved from the addon's directory (then they are deleted by remove.conf)
Ah, good point. That makes sense then. I guess for now I'll just enable DeleteBeforeExtracting as a workaround, and maybe some checks can be added to delete module folders explicitly before unpacking them again.
If HandlePackages is turned on, the packages will be handled both while installing and uninstalling, meaning the module folders will get deleted on uninstall.
If it's turned off, modules won't be handled nor removed, even if there's an addon in "unpacked" state with modules outside.
I'll add some checks and see if that helps, thanks for the info about Directory.Move :)
Unbehandelte Ausnahme: ICSharpCode.SharpZipLib.GZip.GZipException: Error GZIP header, first magic byte doesn't match
bei ICSharpCode.SharpZipLib.GZip.GZipInputStream.ReadHeader()
bei ICSharpCode.SharpZipLib.GZip.GZipInputStream.Read(Byte[] buffer, Int32 offset, Int32 count)
bei System.Xml.XmlTextReaderImpl.InitStreamInput(Uri baseUri, String baseUriStr, Stream stream, Byte[] bytes, Int32 byteCount, Encoding encoding)
bei System.Xml.XmlTextReaderImpl..ctor(String url, Stream input, XmlNameTable nt)
bei System.Xml.XmlDocument.Load(Stream inStream)
bei CmdAceUpdater.Server.GetIndexFile()
bei CmdAceUpdater.Worker.GetAddonList()
bei CmdAceUpdater.Worker.Update()
bei CmdAceUpdater.CmdAceUpdater.Main(String[] Args)
It seems as though index.xml is no longer compressed. Just make these changes to server.cs and you should be good to go:
FileStream fs = new FileStream(FileName, FileMode.Open);
//GZipInputStream gzi = new GZipInputStream(fs); <---- Comment out/remove This Line
Index.Load(fs); <---- Change gzi to fs
I'm not trying to derail this thread, and feel free to tell me to ask this question elsewhere. After the move of the repository to a curse-forge based system, will this updater continue to work?
I have absolutely no idea how the curse-forge repository works but right now, I don't have any plans on maintaining CmdAceUpdater if any major changes to the codebase are needed to make it keep working :)
D:\World of Warcraft\CmdAceUpdater>cmdau -u
CmdAceUpdater v1.0b9
i: starting the ace addons update
Excep??o n?o processada: ICSharpCode.SharpZipLib.GZip.GZipException: Error GZIP
header, first magic byte doesn't match
em ICSharpCode.SharpZipLib.GZip.GZipInputStream.ReadHeader()
em ICSharpCode.SharpZipLib.GZip.GZipInputStream.Read(Byte[] buffer, Int32 off
set, Int32 count)
em System.Xml.XmlTextReaderImpl.InitStreamInput(Uri baseUri, String baseUriSt
r, Stream stream, Byte[] bytes, Int32 byteCount, Encoding encoding)
em System.Xml.XmlTextReaderImpl..ctor(String url, Stream input, XmlNameTable
nt)
em System.Xml.XmlDocument.Load(Stream inStream)
em CmdAceUpdater.Server.GetIndexFile()
em CmdAceUpdater.Worker.GetAddonList()
em CmdAceUpdater.Worker.Update()
em CmdAceUpdater.CmdAceUpdater.Main(String[] Args)
Getting the same error that rh-phoenix had on v1.07b but I'm using v1.0b9.
Don't know if I'm doing anything wrong.
Would appreciate some help! :D
Downloaded the files on 08/08/2008.
Thanks in advance.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Can't reproduce that, it's working perfectly here.
Same with the first bug you mentioned, about not handling packages while updating but working properly when installing. I've tested it with a few packages, double checked the code and, from what I can see, it's fine. Actually, the update and install use the same function to install the addon so there really shouldn't be any problems with it...
According to the log file, everything's working fine, can't really figure out what's really happening on your side, sorry :(
Oh well, it's not a huge deal. Thank you for trying, and I'm sorry I couldn't be more helpful in debugging. >_<
Edit: I went through the code one last time, and the only thing I could find that could be causing my problem is this line in FileSystem.HandlePackage():
According to MSDN, Directory.Move() will fail if the new directory already exists (which would be the case when updating a packaged addon without DeleteBeforeExtracting, as I do). That might explain why you're not having the problem. It still doesn't explain why Remove.conf magically knows where the module subfolders are, though... o.O
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI know i have had to add several Directory.Exists() checks. I havent seen your code though, you may do stuff differently.
EDIT Looking at the code, (just a guess), but the program probably deletes the files in remove.conf, but for some reason doesnt delete the existing module folders when updating them, so only those modules which you have set to delete get moved from the addon's directory (then they are deleted by remove.conf)
WAU moves the directories into and out of the main addon every time it updates, but that is more to allow for recursion. I'm not really sure how your code could work (for packages) without delete before extract on, but i only looked at it for a couple minutes.
Ah, good point. That makes sense then. I guess for now I'll just enable DeleteBeforeExtracting as a workaround, and maybe some checks can be added to delete module folders explicitly before unpacking them again.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf it's turned off, modules won't be handled nor removed, even if there's an addon in "unpacked" state with modules outside.
I'll add some checks and see if that helps, thanks for the info about Directory.Move :)
Changes:
Didn't test it a lot, but it seems to work fine with DeleteBeforeExtracting disabled.
The zips are attached to the first post :)
I'll see what I can do about it :)
Changes:
Changes:
Getting the same error that rh-phoenix had on v1.07b but I'm using v1.0b9.
Don't know if I'm doing anything wrong.
Would appreciate some help! :D
Downloaded the files on 08/08/2008.
Thanks in advance.