Juiceman skrev: >>>> 4) Would it be a good idea (read: worth the time) to make the installer >>>> log its progress to a logfile in the system's temporary folder for >>>> debugging/troubleshooting reasons? >>>> >>>> >>> I don't know that users could find the file if needed. I would log it >>> in the Freenet install folder if it can be, fall back to the folder >>> the installer is running and fall back to the system temporary folder >>> if the others aren't creatable\writable. >>> >>> >> But if the installer actually succeeds, the user most likely doesn't >> want/need the log file - so keeping it after the installation would >> probably be a waste. We won't even know the install folder when we need >> to log the first things btw. On the other hand, admins doing silent >> installs would probably be happy with a logfile even if the install >> succeeds (but they would be doing it via the command-line, where they >> could also specify a log location). >> >> If logged to the temp folder, the installer will delete it during its >> cleanup on an "expected" exit (= it will only remain there if something >> went wrong). But on the other hand, as you mention, the user won't >> realize where he needs to look in the event of a fatal >> crash/freeze/bug/something. >> >> Hmm. >> >> > > So create the log file in the .\ folder (the same folder as installer > is run from, assuming write privledges), always deleting upon success. > Also create a log file in the system temp file, deleting on success? >
That could be a solution. Anyone see a problem with this? >>>> 6) update.cmd was *not* created with concurrent installations in mind >>>> (read: it won't work), and certainly won't be compatible with the >>>> current installer and mine at the same time. The best solution would >>>> probably be to branch update.cmd for my installer. Juiceman, how are you >>>> feeling about it (being the current maintainer)? >>>> >>>> >>>> >>> I haven't worked on it in a while. Why would it not work? It stays >>> in it's own directory and uses relative folders ..\bin etc etc. >>> Unless you are wanting it to update all installations at once (bad >>> idea imo) it just calls stop.cmd does it's thing and calls start.cmd. >>> All agnostic, right? or am I missing something. I assume the new >>> installer will create a start/stop.cmd with the unique nodes' service >>> name? >>> >>> I would be happy to make changes as needed. >>> >>> >> Coolio. I agree that it should only update its own installation. Yes, >> new start.exe and stop.exe bins will be included. They will be generic >> though, as they will read the needed ID info from a file (which you can >> adapt for update.cmd as well :)): >> > > Wait, .exe? > Yea. To start/stop services under Vista, you need to UAC elevate, which cannot be done from a batch script :-/. See http://en.wikipedia.org/wiki/User_Account_Control#Requesting_elevation. Basically we either have to include an .exe manifest (my current solution as it seems like the best approach) or elevate access by "runas"'ing ourselves. >> However, there have been some Vista bug reports regarding various things >> failing because of missing privileges (UAC :-/). So the "cacls" stuff >> might not even work in a .cmd file on Vista, meaning we might have to >> create wrappers for that too (as start.exe/stop.exe which will >> self-elevate on Vista). I still need a Vista test puppy to test that >> kind of stuff though. >> > > I'll have to read up on the cacls stuff, I didn't put that in Toad or > Nextgens did. > > Yuck. I don't have a Vista machine to test on, either. > It's basically chmod for Windows. If we are lucky, the user just gets an UAC promt. If we are unlucky, it fails like "net start" and "net stop" :-/. - Zero3 _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
