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. > >> 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 :)): 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) 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. Basically, since update.cmd is shared among all users and installations (because of the self-update), it must not contain anything installation specific. - Zero3 _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
