I have Vista running, a german and an english version (both 64 bit). So I could test something if needed. (my production node runs on 32-bit XP).
On Tue, Jan 13, 2009 at 19:01, Juiceman <[email protected]> wrote: > -----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 > -- __________________________________________________ GnuPG key: (0x48DBFA8A) Keyserver: pgpkeys.pca.dfn.de Fingerprint: 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A __________________________________________________ _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
