-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Jan 13, 2009 at 6:26 AM, Zero3 wrote: > Juiceman skrev: >>> 2) Is there anything in the folder structure that ought to be moved >>> around? E.g. atm. we have browse.cmd in the install root, but start.cmd >>> and stop.cmd in the bin folder. My installer also creates a new >>> installid.dat file containing a string needed to identify the node among >>> concurrent installations. Is there some kind of guideline about where >>> files should be placed? >>> >> >> I've always thought there should be a \config directory but that would >> require lots of changes in the code. >> > > It would definitely make sense for users wanting to backup their > identity and settings. > >>> 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? >> >>> 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? > > During installation, the installer will "count" previous installations > and append a suffix to various things based on that. To allow > identification of an install dir, it creates a file named > "installid.dat" in the root of the install dir (where update.cmd is also > placed) which will contain either nothing (first install) or a single > line containing a string following this style: "_2", "_3", "_4", etc. > (starting with "_2"). That makes the following IDs: > > Service name: "freenet", "freenet_2", "freenet_3", ... > Shown service name: "Freenet Background Service", "Freenet Background > Service_2", "Freenet Background Service_3", ... > Custom user: "Freenet", "Freenet_2", "Freenet_3", ... > ... same system with other things like start menu and desktop shortcuts > > Install path: Does not depend on suffix. You hopefully already know this > (otherwise you could potentially look it up by going through > services/uninstall entries) > fproxy port: Does not depend on suffix. First unused after 8888 at > install time (look it up in freenet.ini) > fcp port: Does not depend on suffix. First unused after 9481 at install > time (look it up in freenet.ini) > > As far as I can see, here are the things that needs to change in update.cmd > - Several lines with "bin/start.cmd" (-> bin/start.exe, assuming we want > to keep it inside the bin folder) > - Several lines with "bin/stop.cmd" (-> bin/stop.exe, assuming we want > to keep it inside the bin folder) > - Several "net start | find "Freenet 0.7 darknet" > NUL" (should use > dynamic "shown service name") > - Several "echo Y| cacls . /E /T /C /G freenet:f 2> NUL > NUL" (should > use dynamic custom user) > - The downloading of a static wrapper.conf (wrapper.ntservice.name, > wrapper.ntservice.displayname and wrapper.ntservice.account will be > individual now) I'm pretty much with you so far. > > 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. > > Basically, since update.cmd is shared among all users and installations > (because of the self-update), it must not contain anything installation > specific. > > - Zero3 Right. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: http://getfiregpg.org iD8DBQFJbNb24esu1mlKOs8RAgkfAKCeIPHwpGGMrSsf6Qmjd/6KPGFm/wCgnPBR Z7QWJE6TKiJ3MgJyNO7R2E4= =146a -----END PGP SIGNATURE----- _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
