/*------------------------------------------------------------------------*/ /* * * $Id: FixedBugs 1.19 1998/10/27 21:57:27 heinz Exp $ * */ /*------------------------------------------------------------------------*/ Informal list of fixed bugs and changes since Envoy 1.65 ======================================================== [Really important behaviour changes that need to be documented are marked with '!!'] - Crash on aborting examines (C:LIST, CTRL-C). - FindService() returning garbage error codes. - GetHostName() appending LocalHost to the passed buffer for a NULL enitity passed. - Crashes in HostRequestA(). Lousy GUI code. Fixed for now. Should be replaced. - Repaired half a ton of "cast" bugs. Lots of code used inappropriate and sometimes really destructive casts. - NIPCBuffer trashing on local ACTION_READ and ACTION_WRITE. - endless retry on security reject which in essence hangs the client and loads the line. - filesystem.service used to open after one failed open if nipc.library was available, even if the other libraries needed were not. Net result ==> GURU! - ACTION_SET_FILE_SIZE should work now. - hanging lock on security failure when trying to enter a directory. - fs server left locks on failing mount requests for non existing volumes. - on mount fs server reported "doesn't exist" when it in fact rejected the user. - server had serious problems with handling requester suppression on a mount. - ACTION_FH_FROM_LOCK works now. - fcconfig deleted temporary ".info" file manually. It now uses DeleteDiskObject(). - fsconfig did not really fit onto a 640x200 topaz 8 WB. - The fs code and the fs prefs code duplicated many structures and defines which should have been defined in one place only to avoid compatibility breaks. Fixed now. Referencing includes across directories is not nice but a lot better than duplicating their contents arbitrarily. I need to do something about nipc, too. - Cleaned out obsolete intuition identifiers where I found them. - Groups prefs has now a better login. - About menus added to the filesystem prefs editors. - An english locale text for the nipc prefs was too long. Fixed. - Small kludge added to nipc.library to have Envoy 1.65 behaviour on the S2 CopyFromBuffer callback. Envoy 1.65 always returned success on this callback no matter what. Hmm. DO NOT DEPEND ON THIS! - Missing Permit() in FindEntity() code could potentially have stopped the system. - nipc S2 code could leave buffer lying around on low memory. - nipc S2 code did not necessarily queue ARP requests again when the remote side came back into service. - internal nipc S2 packet counters for internal statistics were not handled correctly. Doesn't matter for the user though. This was more a cosmetic fix. - nipc UDP closed connection via Forbid() protection while the list was otherwise semaphore protected. - nipc ARP buffer entry timeout value was wrong by a factor of 10. - nipc doesn't depend on services.library internals anymore. services.library V40(!) has special private access functions now. services manager uses these for locking now, too. - CreateEntityA() made the entity available before it was fully initialised. If this was done just at the "right" time, nipc.library would crash or do other strange things. - nipc RDP made an active connection available on open before having set up all data needed. - gross bugs in nipc RDP handling. The headerlength was not set according to RFC908 and on dataless "flag" packets the wrong sequence number was used! Actually I am not sure if RDP works as described in RFC908/1151 at all. The code looks more like "we do it not quite like they do it" which really is annoying. - dataless RDP packets updated the sequence number of the last ack'ed packet to the current one even if there was no ack! - nipc RDP data acceptance via PacketIn() had major problems: - If a needed packet in sequence did not arrive, it would continue to queue even redundant packets until death. - In two places it had search algorithms with an O(n^2) like brute force approach to the problem. Hmpfh. - it ack'ed segments but did not tell the timeout code that those segments were acked. So the timeout code sent another ack. I rewrote this completely. No reasonable way to fix it without throwing it out. - nipc RDP code would in some cases either dereference NULL pointers or other invalid list pointers, access closed (non existing!) connections, or send spurious resets to the other side with garbage sequence numbers. - On closing nipc RDP connections in the listening state, the RDP code sent a reset to some undiscovered country. - nipc RDP resets were not necessarily obeyed. - While checking on some nipc stuff I found that NIPCConfig would really barf on you if you tried to use the Realm configuration screen. As it turned out, someone used "mlh_Tail" instead of "mlh_TailPred" for walking a list. - nipc AMP code cleared out all the RDP flags when it had been signaled on an available transmit window. '!' was used for inverting a bit mask rather than '~' in three places scattered in BeginTransaction() and ReplyTransaction()! A sure killer IMHO. The same bug was in DeleteEntity() in handling entity flags. Just wondering: How did nipc work at all? ;^) :-( - nipc RDP will now flush still pending writes when they are acknowledged, not only on a timeout run after it has timed out! - On startup nipc will do better checking of any sana2 device it tries to open. This fixes e.g. an open amoksana.device with no HW connected. - If a sana2 device goes into "failure mode" and barfs on any and all requests for some reason, nipc.library would hog the CPU and in effect lock the system. Error handling tries to be smarter now, even though there is no true general solution to the problem. This should help in most cases, though. - FindEntity() messed with an entity after releasing the entity list semaphore. Tiny window, but a window. - password hook in the login requester fixed. Now it is possible to delete a password that is too long and retype it. - printer prefs and Users are now localised. - Strange double click behaviour in Filesystem Imports ListView fixed. - fixed potential holes in nipc sana 2 code that could have messed up sana 2 addresses with a bit count that is not a multipe of eight. - nipc sana 2 code did not clear allocated IORequest memory in all cases. This could have caused strange flag settings etc. !! - nipc ARP will now be used for all HW types, not just for !! ethernet connections. This is an incompatible change but fixes !! the HW address vs. IP address dependency problems. !! - If the user chose defaults for IP and ARP type in the network !! configuration for a device, he will get ethernet values 2048 and 2054 !! unless ARCNET is used. Then 240 and 241 are used as defaults !! in nipc.library. While this is not a good solution at all as it !! doesn't take into account the actual HW available, it will at !! least give reproducible results compared to the "ignore the !! checkmarks and take whatever we have" type of behaviour. - There is a major conceptual problem with RDP sequence number wrap around. This always has and still does completely confuse the RDP code and will in effect make the RDP connection affected unusable and probably flood the net with packet retransmits that are never correctly acknowledged. I am in the process of doing something about this, but this is a _very_ tricky subject. Hopefully my rework of sequence number handling works. This needs more testing. - With my RDP rework I added a new bug affecting the start up of a connection. For fixing this bug I did some heavy RDP debugging. So RDP connections should work a lot better now. Especially starting up an RDP connection should be now as fast as it used to be again. Again, the new release might be incompatible to previous buggy releases. Sorry for the inconvenience. We are now at nipc.library 40.18. - Changed the printspool.service naming convention for jobs from "t:job%ld" to "T:EnvoyPrintJob_%ld" to avoid any conflicts. - Services Configuration should no longer leave filelocks or library opens hanging! It will also default to "/Services" now as directory for adding services (it is based in Configurations!). This should help poor B. J. User somewhat. - Back to the filesystem. ACTION_READ_LINK returned DOSTRUE and ERROR_ACTION_NOT_KNOWN for some strange reason. Fixed. This shouldn't have been a problem anyway as ReadLink() should only be called if ERROR_IS_SOFT_LINK has been returned by the FS, which of course cannot happen. - Found a hole in internal restarts of ExAll type requests. Packets were added to the head of the main FS packet port without any protection at all! - ACTION_MAKE_LINK will now work for hard links. This might e.g. help DUUCP users with a networked news tree. - I decided to finally try it: Record locking should work now. This needs more testing though for reliability. - ACTION_DELETE_OBJECT may take a lot longer for large files than pretty much any other packet. So the default timeout of 6 seconds was not enough and even though the packet succeeded, the network transaction timed out. I bumped the timeout to 18 seconds for a delete. This stuff shouldn't be done via a single transaction, but it is not at all easy to rewrite! Bumping the timeout is not a solution but it'll make the situation at least a lot better for most users. - Really nasty bug on reconnect of a broken network mount. The client passed the full server path of the object in question without the server drive specifier. This could lead to write files popping up in strange places suddenly and read files not to reconnect. Same problem fixed for locks. - ACTION_READ/ACTION_WRITE could still leave buffers lying around on failure. Should be fixed now. - ACTION_READ/ACTION_WRITE would pretty much garble the client seek position on network failure or partial R/W failure. Now a bona fide attempt is done to keep the seek position correct. This might still fail of course, but this is better than not doing anything at all about it. - While an ACTION_READ/ACTION_WRITE is pending all incoming packets for this file handle are saved and queued again after the R/W is complete. The packets were requeued in reversed order and without sufficient list protection. - I found a reproducible case where after a reconnect the client was accessing the root of the mounted server drive where the network volume is located, and not the root of the network volume. - The server did not clean up exall handling for locks discarded on a dead mount. - The client/server had an internal concept of a -1 lock which represented the current server directory on reconnect. No code used this feature for anything useful and it messed up reconnections with volume relative paths. I took it out. Reconnect works volume base relative now. - ACTION_EXAMINE_ALL was commented out on the client side. Why? Because it was totally and absolutely f...ouled up in many subtle ways on both the client and server side. It should work now. Please test this and all the bells and whistles like eac_MatchFunc in detail. Why I did all this work? Because EXAMINE_ALL and all the other examine functions share common code. So I had to fix it. - ACTION_EXAMINE_NEXT could be ended prematurely, pulling out the rug under the client while doing this. - The server tried to filter filenames in the examine calls even if there was no buffer space set up. - Did some autodoc typo fixes in nipc.library. - Tiny change in nipc.library's buffer handling. What is externally visible as AppendNIPCBuff() will now move the list of buffer entries in one piece instead of entry after entry. This saves some CPU time. I improved this on the way as I found a possible cause for an enforcer hit in low memory situations. Found this due to a bug report on nipc enforcer hits that were actually caused by the fs code. - With the fs update, I introduced a bug in R/W buffer handling that could cause enforcer hits in nipc.library under certain network failure situations. Fixed, hopefully. - Interesting enough, I cultivated a bug in exall handling when redoing the exall stuff. The matchstring was passed to the server to filter entries. While this is in theory a neat idea by the C= guys to save on the actual transfer, it doesn't work as I know now. Preparsed patterns are not portable between different dos.library versions. Now all the filtering is done on the client side. This is unfortunately much less efficient. - Another bug was in filtering of exall entries on the client side. It did not remove entries correctly in all cases. - The sana2 code in nipc.library could "forget" to requeue packets for ARP under certain conditions. It also queued read packets for devices known to be offline which is totally useless and hogs the CPU. - Slight rework of R/W packet handling to be on the safe side. I _think_ I found the hole causing spurious enforcer hits via nipc.library once in a while, but I am not sure yet. - "Network Configuration" will no longer force the realm checkboxes set, just because there are entries in the realm lists. This makes it possible to turn off a realmserver without loosing the entered prefs data. - It should be possible now to use the RETURN key in the "Network Configuration" "Host Configuration" panel to hop from gadget to gadget just like with all the other panels. - There is still a bug in the RDP code when a packet sequence number wrap around occurs. I found this based on a hunch regarding the "overnight hanging bug". This bug in effect breaks the connection. I have started to investigate and fix this, and as a result the new nipc.library will once again be absolutely incompatible to previous versions. Sorry. A side effect of my work for a fix is that some fields are now 32 bit aligned which should help on anything >=68020, i.e. >= A1200. - Sequence number wraparound should be ok now. Finally. - Fixed a few holes in the RDP code where a task waiting on RDP permission to send stuff would sleep forever. When this happened due to the sequence number wrap around bug, this connection would effectively hang. This should explain and fix the "overnight hangs" for good. I hope there isn't more of this. We are now at nipc.library 40.24. - Note that nipc will not use trans_Timeout for local transactions currently. So a local entity connection will hang if the destination hangs. The source has no chance to recover. I feel that this is a bug (which is currently hard to fix). What do you think? COMMENTS ARE WELCOME! - The server could show erratic behaviour if you sent paths longer than 128 characters to ACTION_LOCATE/DELETE_OBJECT and ACTION_CREATE_DIR. - ACTION_SET_DATE would return garbage results on a security failure. - ACTION_CHANGE_MODE was flaky with filehandles before. Should work now. - fs server locked a semaphore a few lines to late. No problem with normal use, but still a bug. - On cleaning up dead mounts, the server left a lock lying around. - The client was flaky with timeout settings on reconnect. This could hang a reconnect. - Unlocking NULL locks is not nice, but should be regarded as ok. This is now the case. - Believe it or not, I found another nipc bug. If you deleted a public entity that still had connections pending, it would be silenced as far as possible, but not be made private. This would lead to enforcer hits if a remote side tried to enumerate entities. As a side effect of my fix, FindEntity() will now behave according to spec and only find local entites if they were created with ENT_Public, just like with remote entities. We are now up to nipc.library 40.25. How many revision will there be? - ACTION_DELETE_OBJECT will now run async on the server. It should no longer block server activity for other clients until the delete is done. The client will get a response when the delete is done, but the server is not locked up for other clients in the meantime. - The client is now a little better about doing at least one retry with a prolonged timeout itself before putting up a requester. So timeout requesters will come later now. - EFS should behave _much_better_ now with server drives having RMS. It used to barf in many ways, now it should handle this rather gracefully and hopefully do the right thing in all cases. As this needs truly tons of testing, I hesitate to say that Envoy has RMS now. While the mounts on the client turn up as public entities now, it won't make any sense for a user to FindEntity() them. They are public only to let the server be able to contact them in majik wayz. Please try this with CDx: and DFx: and whatever you got. Note that RMS does not carry across machines. You can't export a volume in df0:, get locks on it on the client, move the disk physically to the client's disk drives and expect it to be recognized. !! - A BEHAVIOUR CHANGE of fs exports. An export with an empty export !! name used to get the clients device mount name. Now it will get !! the true volume name of the servers volume. This makes much more !! sense and an empty name is now the preferred setting for !! exporting a DOS device with RMS. Actually it is probably !! reasonable to say a few things about RMS name handling and !! reconnect behaviour now. As described above the client used to !! have the same name for the volume node as for the client's !! device node if no export name was specified on the server. This !! was not logical, as both the export and import prefs listed the !! server's export path (typically a device name) in this case. In !! this case the client can make much more use of the server's !! volume name. All this does not affect name use of the client at !! all, as of course the device node is still there and any !! reference to that name will now go via the device node instead !! of the volume node. Nothing is lost. The client just has !! additional information available via the correct volume node. !! RMS and reconnect are related to the above. If an export name is !! configured on the server, it will be only used on a mount of an !! inserted volume or a reconnect (which is in effect a remount). !! If no name is configured the true volume name will be used. For !! any disk change, only the true volume nname will be used. Why? !! because having different active volumes with all the same name !! doesn't make much sense. So there is one simple rule now: If you !! export a drive/device with RMS, don't specify an export name. - the server should no longer work with garbage guid/uid's on low memory situations. - I got tired of rebooting, so now the server supports file notification on its prefs file in ENV:. One can change the export configuration on the fly now. The Services Manager will also try to reload its configuration now if it has been changed. Note that this cannot (and probably should not) be done easily for nipc due to how all the stuff works. - Added a "Use" button to the fs export prefs and appropriate menu headers to select env: or envarc: values. Default is empty. - Services Prefs behaved strange when using the "Last Saved" menu. It appended the stuff to the current list of services. - Notification should be working now. Some special notes about this, though: a) Any action done through EFS that should cause a notification of the client, will cause one (Guru Book!). The ROM fs and RAM handler don't do it that way. b) Any action done through the server fs will cause a notification if that fs supports notification for the action. Needed to get notifed of other's accesses. c) As a result, any action done through EFS will cause 1 notification event if only EFS supports it, and 2 notification events if both EFS and the server fs support it. While two events can be annoying at times, they are better than none at all. I have no way to tell which actions on the server side fs will cause a notification by that fs and which won't. Please test this with both signal and message notification and whatever flags there are, and with reconnect! - The login requester password hook was a pain. I removed editing restrictions now to make it work. For users that get lost in typing in dots this means, they probably better kill the contents and retype in some cases. - The printer server should now process spooled client files in 8k chunks instead of 1k chunks. This _might_ help efficiency. - ACTION_WRITE_PROTECT is supported now. It will leave the server untouched and do only client side write protection. - Another change for ACTION_DELETE_OBJECT. While it doesn't block server operation anymore for other mounts, all packets for the client mount of the delete will be queued until the delete is done and processed afterwards. Why? To guarantee sequential behaviour in packet processing. Note: PLEASE TEST THIS! Maybe by sending of an async delete packet and sending other packets before the reply comes in. I don't trust my own tests at all here. This stuff is tricky. - String gadgets in Login/Host requester will be activated on window activation. - String gadget contents in Host requester will now be used even if it wasn't deactivated by TAB/ENTER. - I decided not to do anything about the string gadgets in Network Configuration, Users, and Groups. This doesn't hurt too much and would require some rewrite. - I think I found the "split file on reconnect" bug. Finally. A baselock for a path of a file to open was assumed to be the parent lock of the file itself. So any path specs in the file name got lost on the way which messed up paths for reconnect. - As Dale correctly said, the printer stuff is FUBAR. Unless there are any error reports, I probably won't touch it again. it needs to be rethought and rewritten from scratch. - Due to all the changes outlined above, I decided to call this Envoy 2.0, not 1.8. - Services Configuration has now "Enabled:" again as english label for the checkbox. For = 3.0. This type of "bug fix" has been done to some other prefs editors previously by C=. Probably for the same reason. It doesn't hurt the user interface though. While doing this I found that a) memory was left lying around when adding a bad service b) an asl requester was freed twice while another wasn't freed at all on exit. Automatic reboot included. We are now at 37.13. - Enforcer hit in nipc.library fixed. I introduced this bug with my fixes for 40.25. Now we are at 40.26. - A minor problem with notification in the fs server. Notification was not done for the parent directory of the modified object. Notification for objects referenced with a lock and an empty file name could have been flaky. This should be ok now. I did not mention one other thing before: Notification should theoretically be done on all the hard links of the modified object, too. If you think about it hard, you will realise that this is not possible. This is not a bug. Anyway, the server is now up to 40.29. - This is embarassing. I left in debugging code that delayed a notification setup for > 1 second. Server is now at 40.30. - The AmiCDRom filesystem doesn't seem to set up its struct Resident correctly. This caused hits on volume insertion. I put a kludge into the fs server to compensate for this problem. Now at 40.31. - The client sets the DiskType in the volume nodes now. This should help "Filesystem Imports" to decide on already mounted mounts. Now at 40.41. - Minor typo fixes in some doc files and minor german locale update. - Filesystem Imports complained on empty drives even if the mount was ok. Fixed. It should be a lot better about determining which drives are already mounted, too. The original code had "crashy" tendencies for removable media and did not take device mounts into account. Now at 40.9. - Filesystem Imports will now check only active Envoy mounts to see if they are already mounted. Inactive mounts should be left alone for sure, now. Now at 40.10 - The efs client did some filehandle init it should not have done. Now at 40.42. - The efs client could give enforcer hits if someone did an UnLock() right after an Examine()/ExNext() in just the right timing. A lock was freed twice and invalid memory way referenced in that case. Also freeing a ZERO lock could probably result in unusual behaviour. As all the lock handling code turned out to have some perfectly valid, but obscure areas from the simple readability point of view, I did some beautification work in addition to fixing things. And while this is very ugly behaviour of any application, efs should now be robust against "copied" locks. This last thing is mainly a paranoia fix triggered by my research on the exnext problem which started this. Now at 40.43. - Found some places where lock pointers were set up without a check for the BPTR to be ZERO. This was always ugly and is deadly now. The efs client is up to 40.44 now. - nipc should no longer try to write to sana 2 devices which are definitely known to be offline. This should be cosmetic though. I am still not clear on what is causing problems with ppp.device. But maybe this reduction of io helps finding the actual problem. Now at 40.27. - After some thought I decided to modify the sana 2 device init in nipc to complain loud on any problems. I assume now that the user wants those devices she specified in Network Configuration to work well. Previously only a failure to open a device at all caused an requester to pop up. Now any "fatal" error which will prohibit nipc from setting up and using a device will generate a requester. This should reduce the "doesn't do anything after boot" problems without user notification by about 100%. And it should help fix bugs as you will get to see an error number. nipc.library is now at 40.28. - The EFS client returned ERROR_WRITE_PROTECTED instead of ERROR_DISK_WRITE_PROTECTED on an active ACTION_WRITE_PROTECT. This is fixed now and the EFS client is now at 40.45. - Bumped some versions to allow for a decent HWGRCS version freeze for release. I was unfortunately lazy sometimes. No change in functionality at all. Just a recompile with a new version number. filesystem.service: 40.32 Filesystem Imports: 40.11 Filesystem Exports: 40.9 nipc.library: 40.29 envoy.library: 37.21 services.library: 40.2 !! - I have a hunch concerning the ppp.device problem. It is now !! possible to disable ARP by setting the ARP type to the IP type. !! It counts as unsupported hack, though. I am not sure it will stay !! that way. This does not affect compatibility as it is a normally !! illegal combination of values anyway. Maybe ARP was the problem. !! If this was truly the problem, we need to either document this !! way to turn off ARP or find a more intuitive way to do this !! for the user. Hmm. What about an ARP type of 0 to turn off ARP? !! Hmm. Let's wait on feedback. nipc.library is now at 40.30. - The list of services was not correctly locked by nipc during an inquiry. This could lead to overwritten memory, crashes or similarly nasty things when the list changed at just the right time while an inquiry was active. nipc.library is now at 40.31. - The host requester in envoy.library had rather high stack usage. This should be better now. It could also mess up the system if you specified to many matchtags. This should be better, too. Now at 37.23. - Filesystem Imports had rather high stack usage, too. It also allocated a VisualInfo and never ever freed it. Now at 40.12. !! - Ok, this is it. The IMHO last change before releasing Envoy 2.0. !! The official way to turn ARP off is to set the ARP type to 0 !! now. nipc.library is now at 40.32. !! Not all sana 2 drivers can transmit ARP packets. ARP is !! usually useful on Ethernet, and maybe on ARCNET or amoknet. !! For other sana 2 devices, refer to the respective documentation. *** RELEASE OF ENVOY 2.0, X-MAS 1994 *** - nipc/route.c: There was no release function for routes found with Route(). So DeleteRoute() would not work if a route had ever been used. The route hash value function seemed somewhat messed up. NetMask() called NetNum() for nothing. AddRoute() could return garbage or lose memory. nipc.library is now at 40.33. - Network Configuration could crash if the user reloaded the prefs while a device/realm/route was currently selected in a listview. Now at 37.14. - This is a fix for a documentation bug in this FixedBugs file up to now: "Thanks to Ralph Babel for his Guru book and some good hints on certain things.". Good enough, Ralph? ;^) - There is a bug within the ExAll() handling of BABELCDROMFS 1.2 that really makes Envoy barf bad if you export a CD-ROM drive using this file system. Nothing I can do about it. Ralph Babel is working on a fix. It is probably out already for some time when this text is seen in public places. - The Host requester had no default position on screen. So if the application using it was not specifying a position, anything could happen. The default position for all envoy.library requesters is now centered on screen. If you have any idea on how to neatly keep the last position/size in ENV[ARC?], tell me. Any input welcome. envoy.library is now at 37.24. - The printer import prefs tried to close the accounts.library even though it never opened it. It also used a screen pointer that could have been NULL. Printer Import is now at 40.4. - accounts.library should no longer do unnecessary $4 accesses. Using a central accounts server should be possible. Finally. Set the environment variable "Envoy/AccountsServer" to the appropriate host name, and all account management should be done by Accounts Manager on that host. If the connection fails for some reason or times out after 5 seconds, there will be a couple of retries before accounts.library gives up. Note that this should finally get rid of the distributed accounting file mess. You should set up Accounts Manager on _one_ machine only and run account management there. accounts.library is now at 37.7. - The printer import prefs should look a lot better now for non topaz 8 setups. Printer Import is now at 40.5. - The printer export prefs had pretty much all the problems of the import prefs. There was also a memory loss. Printer Export is now at 40.4. - Pretty much all the printer stuff uses a common include file now for the common things. Except for the client. The client needs to be rewritten from scratch. When I get around to do the rewrite, hopefully Envoy will be useful to do local print spooling without extra hacks! This is all in the future, though. printerimport is now at 40.6, printerexport at 40.5, and the printspool.service is at 40.6. - The autodoc for UserRequestA() was messed up. envoy.library is now at 37.25. - While reworking the printer import/export prefs, I messed up the WB startup of these tools. Fixed now. Printer Import is at 40.7 now, Printer Export at 40.6. - It seems that my accounts.library work is by far too little to fix the problem. I even found a bug in the EFS server. If a list of available mounts was requested and no mounts for an acceptable user/pw combination were found, the server rejected the user instead of returning with an empty list of mounts. The EFS server is now at 40.33. - The accounts.library part in all of the management should be ok now. The library will open even for no server connection as a server may be available at any time on a retry. No more panics should happen if the server link breaks for some reason. The library base was messed up, too. There is still some work necessary on all the other modules related to account management. accounts.library is now at 37.10. - The realm and routing panels, and adding a device in Network Configuration worked basically by accident only. The gadget functions were using a taglist without a trailing TAG_DONE. Network Configuration should be smarter about adding devices now. At least it tries to check if the device is a SANA-II device before adding it. There was also the possibility that an asl requester was not freed. Network Configuration is now at 37.15. - For some reason unknown to me the IP protocol number used for the RDP implementation has always been off by one. According to RFC1060 it should be 27, and it has always been 26. Fixed. There was also an interesting problem with subnet masks. Subnet masks are in essence and very informally put a "larger" netmask, i.e. based on the standard net mask an ip address has, they define additional bits taken from the host part of the ip address to be used as subnet for routing purposes. This also means that in any reasonable subnet mask, all the bits of the netmask for the relevant ip address need to be set anyway if the sub net mask should be used as "better" replacement for the net mask which nipc does. nipc.library will now make this happen if the user failed to specify the netmask bits in the subnet mask. Network Configuration might do more checks in the future. Routing and realms did not work well together due to wrong handling of network masks for devices not using the subnet mask and wrong handling of source addresses. This could have caused a loss of information about the network on an NIPCInquiry() call and possibly an Enforcer hit for a certain mostly useless nipc configuration. All of this is a sensitive area, so it needs lots of testing. !! Note: This nipc.library is not backwards compatible due to the !! protocol number change! nipc.library is now at 40.34. - SANA-II R2 S2_PacketFilter is now supported by nipc. The private AS225 communication hack will only be active if AS225 is installed and the device in question does not support SANA-II R2. It should be possible now to use e.g. AmiTCP 4 and Envoy on the same S2R2 complying device driver without having to fiddle with packet types. nipc.library is now at 40.35. - The Filesystem Export configuration editor created an empty configuration file instead of at least a valid IFF FORM when no exported volumes were set. The server did not accept this empty file as valid configuration and did not update its configuration accordingly. Filesystem Exports is now at 40.10. - The EFS server did not accept an empty IFF FORM either. It is now at 40.35. !! - nipc.library should pick up configuration changes to the realm and !! route panels via notification. It won't pick up changes to the device !! panel and there are reasons for this behaviour. Note that you should !! know what you are trying to do when you use this. nipc.library will !! simply take out the old realms and route configs and put in your new !! selections. This might affect ongoing stuff and you might loose !! packets. TEST THIS, PLEASE! nipc.library is now at 40.36. - To support the change mentioned above, Network Configuration now has a "Use" gadget. Remember: "Use" won't work for the device panel! Not much I can do about this inconsistency right now. Network Configuration is now at 37.16. - nipc.library left a resolver port lying around on exit. It also used a strange and dangerous seglist splitting hack on cleanup. This is fixed now and a decent shutdown is done. packet filtering should work well now with my new version of my a2060.device. Quite a few changes to how the resolver handled ip addresses. This was not exactly ok. While doing this I had to relayout the routing code. So we might have a ton of problems now. TEST ROUTING, REALMS, AND MULTIPLE PROTOCOL STACKS, PLEASE! For this nipc.library, you will have to upgrade my a2060.device to at least 40.6. Unfortunately the old version had bugs in packet filtering which would not do nice things. nipc.library is now at 40.37. - The requesters in envoy.library could leave a VisualInfo unfreed. They also did not return failure when they could not be opened for some reason. The autodocs were not exactly correct either and I added Window and OptimWindow tags to all of the requesters now to make it easier on the user. The layout code is not yet optimal, but it's getting better. envoy.library is now at 37.27. - Filesystem Exports did not free the VisualInfo it obtained. It is now at 40.11. - Filesystem Imports uses the new envoy.library tags now. This should give visually very attractive results when envoy.library is done. it is now at 40.13. - Users and Groups behaved rather different in some areas. They should both look and behave similarly now. Also the name gadget is activated when you create a new user/group and they both handle the AccountsServer hopefully correctly! They both used standard gadget calls on gadtools gadgets and did not correctly handle the listview updates. Users is now at 37.16. Groups is now at 37.14. - ICMP handling in nipc.library could leave a buffer lying around if no route for a packet could be found. The packet filtering should work better now and will hopefully avoid unnecessary CPU load when multiple protocol stacks are in use. Memory handling for all the buffers should be more unified and straightforward internally now. Some internal caching code for the buffer handling should speed up memory handling a little. Memory use has increased a little. nipc.library will now clean up any pending resolver messages on exit. It used to simply delete the internal port which cause a delayed crash when the pending message finally returned after the library was gone. Handling transactions should be more robust when the user passed garbage input. nipc.library is now at 40.39. - Printer Import now blocks the main window on using envoy.library requesters. It is now at 40.8. - Printer Export now blocks the main window on using envoy.library requesters. It is now at 40.7. - The Accounts Manager did not handle tool types parsing for WB startup correctly. There was a potential memory leak. I intentionally changed the WB argument parsing a little. Only the tooltypes of the program itself will be checked, not those of any project icon used. It helps updates and installation to have a project icon instead of the real thing in SYS:WBStartup and maybe in some other places. But it for sure doesn't make sense at all if due to wrong configuration the manager picks up different database files for different project icons. It also forgot to free memory on exit. Accounts Manager is now at 37.15. - Services Manager lost memory on exit. It is now at 40.3. - I created to simple project icons for the managers which will be used to startup them via WBStartup. I still have to change the install script to support this, though. The default place for these icons are the manager's directories. They'll be copied to WBStartup by the installation and can be copied to arbitrary places by the user. This should finally stop the "multiple managers floating around" problem. - With this update to the EFS client, the 2.04 C:Info should work again. I overlooked a suggestion in the (great) Guru Book. Sorry. The client is now at 40.47. - If accounts.library completely failed to contact the host listed as server, it will reevaluate the server name on the next command. This is to give the user a chance to correct typos in ENV:Envoy/AccountsServer on a running system without a reboot. accounts.library is now at 37.11. - The EFS server will now use an input handler to check on disk changes. I did this to get rid of the excessive locking done to detect disk changes. It should have done it like this all along. Note that the EFS server now relies on the underlying filesystem doing correct diskchange notification via the input.device queue. I also changed the server task name. The EFS server is now at 40.36. - accounts.library will only retry once to contact the server now. It used to do this three times. With internal nipc.library handling of retries this time added up considerably without any real use. accounts.library is now at 37.12. - Another change to password hook handling. It still didn't work quite right it seems. envoy.library is now at 37.28. - Used the same hook code in Users now. Users is now at 37.17. - Network Configuration should no longer loose the realm server name/address when use of a realm server is turned off. Please check if this affects nipc.library in any way. It shouldn't, but who knows where bugs hide. Network Configuration is now at 37.17. - The password edit hook really gets on my nerves. Now, it should finally work better. "Finally"? Hah! Data vu. Let's wait and see. Exiting the login requester via TAB is no longer possible. envoy.library is now at 37.29. - Same password hook change to Users. Users is now at 37.18. - Groups will now resort the listview on a group name change. Groups is now at 37.15. - Printer Export had a mungwall hit on adding a group. It is now at 40.9. - nipc.library should now recognize its officially assigned UDP port number and filter all other packets. There was also another routing problem within the resolver code for realm servers. nipc.library is now at 40.41. - I think I found the cause for spurious "Can't connect to host bla" messages. FindService() wasn't really geared up to handle multiple simultaneous calls and would return failure in this case. services.library is now at 40.3. - Network Configuration accepted owner names > 31 characters in length even though it couldn't handle this (i.e. crashed) under certain circumstances. Realm name gadgets weren't handled correctly either for input >19 characters. Network Configuration is now at 37.19. - On loading the current work prefs, Network Configuration freed any and all old prefs, even the initial ones. It also did not update the display correctly. It is now at 37.20. - Services Manager did not free the list of services correctly on exit. It would not even not free the list correctly. Actually, I don't know why Services Manager did not crash on exit. Magic? Who knows. Anyway, it is now at 40.4. - ACTION_FH_FROM_LOCK has been broken again since I introduced RMS due to a really dumb single character typo. The EFS server is now at 40.37. - Slight rework to the mount handling in Filesystem Imports. If I get around to implement a better mount name handling this should help. As a positive side effect of the work the listview is now sorted alphabetically. Filesystem Imports is now at 40.14. - I learned something new about the AS225 backdoor. When Envoy connected to AS225 through the backdoor, all packets _had_ to go through this hack internally and the multiple protocol stack support of a device driver would be ignored. Ugly, really ugly. As we have SANA2R2 complying device drivers for both ARCNET and Ethernet and packet filtering support in Envoy, I took out the backdoor completely. Less code and a little less overhead. !! Note that you have to use SANA2R2 compliant device drivers now if you !! want to use Envoy and AS225 together. I also removed an ancient paranoia hack related to the CopyFromBuffer() implementation used for communicating with S2 device drivers. I also changed the CopyFromBuffer() and CopyToBuffer() implementations to work a little better. Please tell me if you encounter any problems with AS225 or derivatives thereof or any device driver out there. nipc.library is now at 40.43. - The EFS server could pass a ZERO lock to an Examine() it used. While this should not be harmful, it turns out that it can be harmful. I am kludging around problems in other people's SW here. filesystem.service is now at 40.38. - It happened once in a while that the EFS client returned ERROR_OBJECT_NOT_FOUND on previously valid file handles or locks. This is an indication that they could not be reestablished after a network failure for some reason. Even if the server and the networking hw works correctly it could happen that locks or fh's could not be reestablished because when they were initially set up, some path information about the server location was not checked. Now locks/fh's won't even be created by the EFS client if this necessary path information cannot be obtained. EnvoyFileSystem is now at 40.48. - Some cleanups and link rearrangements done to nipc.library. Took out a few obsolete lines and moved some code around. No bug fix of any kind and I hope I did not introduce any. Please do some diskspeed tests with all sorts of hardware. Packet filtering slowed down nipc somewhat. I am thinking about adding some sort of option to completely turn off packet filtering for the power user who doesn't use Envoy together with some other protocol stack, but I need more input on this topic first. nipc.library is now at 40.44. - nipc.library versions beyond 40.45 will be able to do packet filtering depending on the settings of the new Network Configuration gadget to turn packet filtering on/off. Default is "on" and the power user can turn it off whenever she/he wants. Note that the locale catalog had to change for this! Network Configuration is now at 37.21. - envoy.library had severe startup problems. Anything beyond one open was hazardous. Any failing open would crash the system. Any close on a system with >= OS 2.1 could jeopardize stability. Expunge wasn't safe or correctly done either. Interesting enough I needed a 2.1 test setup to actually reproduce the problems. 3.1 would pretty much handle it great even with those bugs. Special thanks to Dave for locating the source of trouble. envoy.library is now at 37.30. About here I froze the 2.0b patch. - nipc.library had a bug which would mess up an expunge. This should be fixed now. Cleaned up some sources to make them more readable and once again changed the resolver handling of realm server queries. Also evaluates the packet filtering config flag now. nipc.library is now at 40.45. - The EFS client will now use unique volume names by appending a decimal number to the name if it can't use the true name due to a name clash. It used to do a time stamp hack. It is now at 40.49. - Some changes to nipc.library. If you tried to delete an Entity that had not been lost by all remote users yet, you would be left with an unusable entity that you could not get rid of. This should be fixed now. The resolver should handle multiple remote realm entries for one realm correctly now and due to some heavy magic, there is a good chance that PPP connected hosts can be added to a realm now without any hassle. The trick is not to specify the PPP connected host via its subnet in "Local Realms", but with its IP address in "Remote Realms". This is really heavy magic! nipc.library might be slightly faster now. Hmm. We'll see. nipc.library is now at 40.46. - The EFS server will now use the baselock instead of a ZERO lock to get the volume name for an RMS export. It also will no longer try to use any export path that refers to a file. All of this has subtle consequences affecting only those users that do not have correct configurations. filesystem.service is now at 40.39. - I hacked away on the printspool.service to test some new concepts. Printing is done differently now. All printing is done on the Amiga where printer.device has been opened. This has not changed. The raw data stream is then rerouted via envoyprint.device to the printspool.service on the configured print server. This works even for the server machine now! The printspool.service will put this data to the configured underlying device (parallel/seriell or PUNT prefs if configured) and do its own timeout handling including a raw "nag" requester. Note that PUNT in the service config cannot currently be set via the prefs editors. So you can test this only with seriell/parallel. The setting will be taken from the current printer prefs on the server. Again, this is just a hack to test some new concepts. A final printspool.service would do some things in a different way. Actually all of the printer stuff will probably look different, but the current stuff is good enought to test things before really getting into a rewrite. Oh, the printspool.service timeout for outgoing data blocks is currently set to 30 seconds. printspool.service is at 40.8. - The EFS server will switch to an ExAll emulation via Examine()/ExNext() now if a) it finds a C= filesystem with known ExAll bugs that can't really be handled safely. b) the user sets a flag in the export config (which is not yet implemented there) Thanks to Ralph for some hints on what is wrong with ExAll(). filesystem.service is now at 40.40. - Filesystem Imports will now put permanent mounts into SYS:DEVS/DosDrivers instead of DEVS:DosDrivers. This should help on booting machines where the DEVS: assign has been changed. Filesystem Imports is now at 40.15. - A new member of the Envoy family has been born after a ~24 hour pregnancy of my A3000: Envoy_port-handler. It will replace the standard port-handler to allow for redirection of SER:/PAR: in case of network printing. This is needed for dumb SW like FinalWriter which insists on using SER: or PAR: for PostScript printing. Currently the handler does not have this redirection feature yet because I need to redefine the import prefs first. Features it has compared to port-handler 40.1: - timeout requester on SER:/PAR: after 30 seconds. This is currently for debugging, but it could be refined and localized. Issue: How to configure the timeout values? Via the printer import prefs? This works even without Envoy so this might be the wrong place. Hmm. - Correct results for Seek and SetFileSize packets. - Should not barf on multiple queued packets. - PAR:FAST and PAR:SLOW to set those bits. - PRT:TRUERAW to use PRD_RAWWRITE instead of the Escape sequence. - Does not do a Stricmp() on BSTRs or BSTR checking without taking the length into account. - Does not skip allocation checks on startup. Note that most of the above is yet untested. Please test the "SER:baud/bla" specifications and similar stuff in depth if possible. This testing is really important. We can't have bugs here! [Oh how I wish port-handler had been converted to use a GlobVec != 0 for >=2.0 in spite of all those 1.3 disks out there.] This first test release of Envoy_port-handler has been frozen at version 42.4. - Enforcer hits on large read/writes with transfer errors made me look very hard at nipc.library again. I found several places with inadequate semaphore locking of shared structures. I also rewrote some rather strange loops. Lots of cleanup changes to the transaction/entity code. As a positive side effect, transaction handling should be even faster now. As I cannot reproduce the hits myself even though it was possible to identify at least one possible cause, I can only hope you really, really, test this! nipc.library is now at 40.47. I hope it works well. - Along the way I changed the general compiler option files for all of Envoy. This gives better results overall, which justifies this major change. A full rebuild will come along eventually. The betas will pick up this change automatically. - nipc.library still had a very strange connection to services.library. I removed this code. nipc.library is now at 40.48. - The counterpart in services.library has been removed, too. There was also a bug in the failure path of open code. services.library is now at 40.5. - Some strange version mixup with Services Manager. To be on the safe side I bumped the version and rebuilt it. Services Manager is now at 40.5. - Filesystem Exports now uses a cycle gadget to set the security options. The left over checkbox gadget has been turned into a 'no ExAll()' flag to support filesystem.service >=40.40. Note that the catalog had to change for this, too! Filesystem Exports is now at 40.13. - envoyprint.device is now sending a sequence number with every transaction. This is of course not backwards compatible, but even envoyprint.device will be replaced eventually anyway. I need this for testing of the new server stuff. envoyprint.device is now at 40.4. - The cycle gadget in Filesystem Exports has now the "correct" height. The listviews will be sorted alphabetically now. Filesystem Exports is now at 40.15. - The hunt for bugs in nipc continues. Ralph found some ugly enforcer hits and memory list screw ups that occurred under (IMHO) heavy transfer load. When looking at them it turned out to be a totally timing dependent problem. I could not reproduce it myself, but I found two possible causes and fixed them. I'd need a darn fast machine, a special networking setup, and task switches at just the right time to reproduce those bugs. nipc.library also released a semaphore it never obtained on some failure path and one of the internal copy functions was really broken. Fixing the last thing was cosmetic though, as the broken part is currently not used anyway. For this release of nipc.library I disabled the use of memory pools which results in a slow library that is easy to debug. All allocations will go straight to AllocMem and I ask you to run mungwall with periodic "munglist check" runs to find problems immediately, not only after a whole memory pool got screwed up. If you find any memory trashing, I would need a dump of the memory regions in question in addition to all the hit and/or alert messages with segtracer hunk info if possible. This debugging release of nipc.library is at 40.49. - filesystem.service had a few bugs. For full security logins with an "other" user, it returned messed up protection bits under certain circumstances. This should be fixed now. I still have to fix the "rename security" and "reconnect while deleting" bugs. One step at a time though. filesystem.service is now at 40.41. - Bugs always turn up in amounts well > 1 after nothing has happened for a long time. The "reconnect while deleting" bug was due to a race condition on reconnect that also affected "notification maintenance on volume removal". Both usually lead to an instant death of the server. The "rename security" bug was only part of the problem. SetOwner and SetProtection were affected, too. Please test security. There also was a potential problem with memory loss when a broken prefs file was read in. The server side now tries to compensate for the V36/37 Seek() bug, too. filesystem.service is now at 40.43. !! - To test the fixes for the server security handling, I made an !! internal enhancement to the EFS client. While doing this I found a !! potential problem in the Seek() handling that could cause strange !! results when a reconnect or relative seek followed a failing seek. As !! a positive side effect of the work I did on this, a Seek(fh, 0, !! OFFSET_CURRENT) should be _fast_ now. Please test seeking, including !! failing seeks in all directions and modes in detail. Please, please, !! please! EnvoyFileSystem is now at 40.50. - nipc.library has seen major analysis work now. I found and fixed two bugs with the RDP management. It would accept packets on closed connections and happily leave the buffer lying around that contained the RDP packet that caused a connection to close. There was a timing hole where transactions buffers could have been freed twice on a fast machine. Also there have been tons of changes to the Entity system already. Losing and deleting entities wasn't always safe. Except for the RDP problems, all the other stuff dates back to the 1.x days. Just a few lines of comments here, but MAJOR CHANGES INSIDE. nipc.library is now at 40.50. - nipc.library should no longer give enforcer hits after filesystem.service hasn't been accessed over a remote link over 30 minutes. nipc.library is now at 40.51. - Still a problem with notification handling due to the changes to get the async delete fixed. Also the dead mount timeout handling was strange now. The EFS server simply killed any mount that hadn't been used for 30 minutes. Now it will kill this mount only if the client can no longer be ping'ed. The client needs to reconnect in this case! filesystem.service is now at 40.46. - Another one "bytes" the dust. Reconnect to a mount on a subdir, not on a server root, didn't necessarily do what you expected. The server "just said no". filesystem.service is now at 40.47. - Cleanup on the EFS client. It is LIBCODE now! EnvoyFileSystem is at 40.51. - I just stumbled over a strange SAS bug. GO inlining of a single use static function (which is called via a cast as LIBCODE __asm with A6 as paramater!) by using OPTINLOCAL messes up the A6 passing. Guru. Simple work around. Don't make the called function static so it won't get inlined or declare it as __asm to avoid inlining. Thanks for the hint, Steve! EnvoyFileSystem is now at 40.52. - Fixed a problem within the EFS server. The check to avoid an import of a file instead of a directory was a noop due to a missing line of code. filesystem.service is now at 40.49. - If a connection died, nipc would try to release a semaphore that no longer existed. nipc.library is now at 40.53. - nipc.library could overwrite buffer memory if Entities were created while a network query was in progress. A slight change to transaction handling should reduce memory fragmentation. Reenabled pools as they don't seem to cause problems at all. Disabling didn't help finding problems either. So I might as well use them again and reduce fragmentation this way. nipc.library is now at 40.54. - The client will do a check now if a lock is freed twice. EnvoyFileSystem is now at 40.53. - Reworked a2060.device because it wasn't flushing correctly and had a potential problem with multiple protocol stack use. The flushing bug got in my way on nipc testing, so I decided to do some work here. BTW, it should spend _less_ time in Disable() than the original C= device. It might spend more time in a soft interrupt though, depending on the load of incoming data. My a2060.device is now at 40.8. - The "No ExAll()" gadget in Filesystem Exports couldn't be used due to a bug in the gadget code. Gadget sizes should be correct now, too. While doing this, I also killed the obsolete startup code. Filesystem Exports is now at 40.18. - A few more fixes to the WB startup handling of Filesystem Exports. It is now at 40.20. - Services Configuration now has a "Use" button. I should have done this for 2.0. Oh well. The gadget sizes match common usage, now. The listview should appear sorted now. Services Configuration is now at 37.15. - There was a bug in the filesystem.service that really messed up closing the service with CloseLibrary. A garbage seglist value could have been returned which would pretty much trash the system right away. I introduced this bug at 40.42 when I replaced the old library handling code. filesystem.service is now at 40.50. - Network Configuration should now have a correct english title, standard gadget sizes, and sorted listviews. Network Configuration is now at 37.22. !! - I made an important change to the Accounts Manager enhancing !! security. User and Group information will now be written out in !! encrypted form. Conversion of old, unencrypted information is !! automatic on the next database change. So if you want to have your !! database encrypted, just add and remove a dummy user/group to have !! the database written to disk. Accounts Manager is now at 37.16. - My fix for reconnect on files in EFS messed up Lock() of a file and Open(""). This should work again now. Also DupLock() should work on files/dirs now that do not have the execute protection bit set. We now have support for fixing the seek position on r/w operations automatically if the client supports this feature. filesystem.service is now at 40.52. - The EFS client supports handling the seek position during split r/w operations now. There should be NO WAY to mess up the seek position, even for split r/w's with network failures now, if the server side supports the additional info passed. This affects performance. Please make diskspeed tests, telling me on which HW combinations with which buffer sizes you experience what kind of performance hit. EnvoyFileSystem is now at 40.54. - A slight change to ARP handling in nipc.library should improve connection startup by reducing unnecessary traffic. I doubt it is measurable, though. nipc.library is now at 40.55. - Async R/W handling inside the EFS client was broken. it could reply twice to a single packet which would crash the machine. EnvoyFileSystem is now at 40.55. - The Accounts Manager encryption messed up all the admin flags. Accounts Manager is now at 37.17. - Due to stupid US laws Accounts Manager doesn't really do any encryption anymore. It just uses ROT13 now. Accounts Manager is now at 37.18. - Filesystem Imports had a very strange bug in doing string parsing. If the locale.library base was just on a 256 byte boundary (i.e. the low byte of its address was 0 or if it wasn't installed!), one could not really mount anything. This in effect makes it impossible to use it on V37. Ouch. Filesystem Imports is now at 40.17. - Due to a memory allocation without MEMF_CLEAN and a missing preset, any internal volume structure created by the EFS server was no longer freed, even if it was unused. filesystem.service is now at 40.53. - envoyprint.device never freed returning transactions. Ouch. While the functionality is pretty much what I need for the new printing system now, I'll most likely do a rewrite eventually to make this nice and shiny. envoyprint.device is now at 40.5 - accounts.library had a problem in the expunge code. This is fixed now. accounts.library is now at 37.15. - services.library had a problem in the expunge code. This is fixed now. services.library is now at 40.7. - nipc.library took an invalid shortcut to IP handling for any local packets to be sent out. These packets will now be handled just like any other packets via the general protocol input handling. In general there was the strange assumption that an IP packet must have a fixed header length. Of course this would have killed any "advanced" setup. The changes should have reduced the overhead in processing packets a tiny little bit. The protocols shouldn't fiddle too much with IP packet headers any longer. This can count as pretty major change. The UDP code will now do checksum tests, too. There was a potential problem in IP address handling of packets that were sent and received locally only. IP packets that may not be fragmented will not be fragmented now. Route hashing should now be a little better. There was also a cosmetic problem in the resolver code which incidentally did not crash anything. I cleaned it up anyway. Registered IP protocols are now checked according to their "priority", e.g. RDP is more important than UDP for Envoy, so an incoming IP packet will be tested for RDP before UDP. ICMP currently is the lowest priority, i.e. it will be checked last. This should help efficiency in packet processing. The IP layer should now pass on and filter options in the packet header correctly. netprobe showed me an interesting autodoc deficiency while debugging all of the above. I added an important note to the NIPCInquiryA() autodoc. There also was an interesting problem in the Expunge handling of this library which could potentially affect system stability. Usage of the LIBCODE getreg hack has been reduced by a fairly simple but basic change. This made the code slightly better and reduced the compiler dependency. All of the above counts as intermediate step. Full ICMP functionality is still missing. nipc.library is now at 40.56. !! - The RDP checksum handling was messed up. I wonder how this !! worked at all. Fixing this makes RDP work according to specs !! of course. nipc.library is IMHO once again incompatible to !! previous versions. I also added a missing initialisation for !! dataless packets to the RDP code. This could have caused !! strange retries. nipc.library is now at 40.57. !! - To be RFC compliant in its IP handling, nipc needs a new flag !! "Is Gateway". This cannot be determined from the current !! settings. I updated Network Configuration to include a gadget !! for this. Note that the catalogs changed for this! Old !! configurations will default to a NON GATEWAY setting. This !! is less dangerous and in most cases does the correct thing. !! It will also finally handle the case where the extra realm !! panels/gadgets are displayed and the user reverts to a no !! realm config via the menu. Network Configuration is now at !! 37.23. - I started adding use of the gateway flag to nipc.library. Finally, I will be able to complete ICMP handling inside nipc because of this, too. - EnvoyFileSystem could still get mighty confused on async R/W packets. Heck, it could even get confused on packets in sync. It will no longer force a reconnect if a R/W failed because of a low memory condition. I also reworked the retry handling. It's hopefully continously getting better and more straightforward. It was a mess with a zillion failure paths. There also was a bug where a failed R/W could get the client into an endless loop. The client would also happily retry already aborted R/W actions. For a failed ACTION_END, the internal file handle would not always be cleaned up correctly. I should split up client.c. It is about 4 times that size that is IMHO acceptable for a source file when I count the lines. But if I split it up, the optimizer cannot do such a great job. :-( EnvoyFileSystem is now at 40.56. - There was still at least one retry problem that could cause requester suppression. The retry count will now be reset whenever a successful connection has been made and whenever a requester popped up because of a failure. I also implemented ACTION_INHIBIT. Not that it makes a fat lot of sense, but I noticed that Workbench uses Inhibit() for a nasty internal hack. So I implemented the packet. I didn't really test it yet! It actually doesn't help Workbench either as the nasty hack wants to see a true exec device name inside fssm_Device. The EFS client doesn't have this of course. It might come in handy for testing though because ACTION_INHIBIT will only shut down packet processing and volume list updates. Internal client activity should proceed as usual. It is not a packet that is put through to the server. That wouldn't make too much sense anyway and it would only confuse things. The client could happily clean up a volume node even if there were still pending notifications. I also put in basic ACTION_DIE handling for easier testing. Note that ACTION_DIE is not supported in general because there is no real safe way to implement it. If you don't know exactly what you are doing with it, you will most likely cause a nasty crash! Async R/W's still didn't work. There were several problems in the handling of returned R/W transactions. Thanks to the awful lossiness of AmigaLink ;^), I could easily test this without artificially creating major networking setups. Just try a "LIST DF0: ALL" with AmigaLink to disrupt network transfers nicely. A sneaky method to test the stuff with fairly reproducible results. I never thought that this would actually come in handy. Kai, I hope the device open/expunge will be fixed soon, too! If large R/W's fail due to network overload, the machine should finally no longer die a slow reconnect death! Also the machine will not unnecessarily reconnect for aborted old R/W transaction any longer. Downtimes on overload should be reduced. The R/W changes probably affect performance a little. The overhead for every single R/W has been and still is noticable, the overhead if one R/W needs to be split (which currently happens for requests > 32KB) is not that bad. At least a R/W will _always_ be at the correct seek position with the current EFS client/server. This hasn't always been the case. If you see a noticable performance problem that you can back up with numbers, I might put some extra work into the problem. EnvoyFileSystem is now at 40.57. - Even more changes to EnvoyFileSystem R/W and reconnect handling. Every R/W should now have one less AllocMem/FreeMem combination and therefore one failure path less. Previously, the dynamic delay feature to compensate for slow networks was only used if a reconnect failed already once. Now it will be used if a transaction times out which IMHO makes more sense. The old style could cause a FOREVER { handle some packets handle a packet with a transation timeout reconnect successfully } cycle without any timeout correction. The new cycle will increase the dynamic delay before trying to reconnect. We also do another stunt to avoid a reconnect. On the first try to reconnect, we ping the current destination. If the ping was successful, we simply keep the connection. This will happen only on the _first_ try to reconnect for a failed transaction and should catch isolated timeout occurrences due to network load. By not doing the ping on succeeding tries, we avoid successfully pinging a dead filesystem.service forever. All of this is to avoid unnecessary reconnects which are essentially identical to remounts including all filehandles, locks, etc. - The PingEntity() function in nipc.library was broken. It did not handle limit values >= 1 second well and maybe even confused timer.device. nipc.library is now at 40.58. - The EFS reconnect handling is a nasty thing on both sides. While checking all of this I found a bug in the debugging shutdown code of the server which prevented a restart without flushing it out of memory. Finally the Server should truly generate unique ID's for identifying mounts. Previously it used the memory address of internal mount data which could of course be identical on a reboot. This could have confused the client really bad and possibly crashed the server. Now it uses the current system time when creating the mount with a little additional magic. This should be a better unique value, based on the assumption that on a halfway decent server we have a halfway decent clock. The server check when to discard unused mounts no longer uses PingEntity(). That means the server won't block anymore for a few seconds when it tries to detect a bad mount. After a mount has not been used for 30 minutes, the server will now send out a dummy diskchange notification to the client. The client won't act on this in any major way if the volume information did not change in the meantime. If the client's response comes back to the server, the server will restart its "unused" timer. Otherwise it will assume that the client is dead and kill the mount. The server used to return a "user reject" error if it couldn't find a mount for a packet. It will return a "no mount" error now which is IMHO a lot more appropriate. filesystem.service is now at 40.54. - Reworked reconnect on the client once again. Before actually reconnecting, it will now try to send an ACTION_INHIBIT FALSE to the server. As the server does not implement this packet, this doesn't do any harm. If the transaction succeeds, we can safely assume that this mount is still alive. This should fix excessive reconnects because of spurious timeouts. PingEntity() wasn't such a good idea anyway as it can't check if the mount is still available. !! This is a DEBUGGING release with kprintf output on reconnect! !! Please send me sushi logs for any problems you find! EnvoyFileSystem is now at 40.58. - For testing the nipc and EFS stuff I had to chose hosts and log in and out of my test setup about a million times. As I am a A2024 user with a setup CGTimes 30/courier 18, the requesters of envoy.library that were only "almost" font sensitive really got on my nerves. The host and user/group requester should now pick up the system font setup correctly. The host requester should use a lot less stack now, too. I also tried to make the sizing visually more attractive by rmeoving the gadgets on a IDCMP_SIZEVERIFY message. It turned out though, that even this "do almost nothing" is IMHO too much for verify handling and confuses the poor user who wants to quickly size a window. So I took this out again. I guess we'll have to wait for a nice, small, fast, and resizable V44 gadtools ;^). Please check these major GUI changes for memory leaks etc. envoy.library is now at 37.32. - BIG problem in nipc.library. Probably since at least 40.50. I didn't really do research on this bug in the archives as it wouldn't have helped anyway. If a failing transaction (request or reply) only arrived in fragments due to some network problem, these fragments could show up in the next successful transaction. Hmpf. I spent tons of time on improving SANA, IP, and RDP handling and reworked the Entity chaos. What do I get? A major problem in the Transaction code. Why nobody noticed this before? EFS used to do a brute force reconnect on a transaction failure. This meant losing and finding the remote entity again. The brute force reconnect cleaned up these fragments. So while the problem was there, it hardly ever surfaced. Now we have a more sophisticated reconnect handling in EFS and the bug showed. Please tell me if performance is affected! nipc.library is now at 40.59. - The Network Printing tool will now handle ENV: and ENVARC: prefs separately when setting up or removing Envoy printing. This keeps current printer prefs intact if they differ from the saved prefs. Network Printing is now at 37.5. - nipc still didn't work correctly. I didn't notice it because I concentrated on packet loss and data messups and tested this with AmokNet HW. This HW can be classified as "slow", and for slow HW, nipc did not use IP fragmentation to keep overhead small. This means that I did not notice the bugs that I introduced in the IP fragmentation code after 40.55 at all. Some pointers were not always set up correctly and the packet ID's could be very messy at times. Ouch. I wish I had a spare A3k or A4k here to set up a really nice test environment with both AmokNet and Ethernet. Oh well. I also replaced some strange Forbid() handling with decent semaphore calls. It isn't good style to change too much at once, I know. This time I couldn't resist. I hate Forbid(). This nipc release has been tested with lossy AmokNet HW with and without fragmented packets by artificially affecting the maximum allowed data packet size. Looks good here. Yes, this time I actually _checked_ if fragmented packets were handled. Hopefully this fixes your problems on standard networks. If this release works for you, I'd be very interested in performance data. nipc.library is now at 40.60. - FindEntity() would not set the error information correctly in rare cases of network failure. The RDP code will now use a cache for internal retransmit information. Previously it allocated a wrapper per packet. Now it will allocate at most n wrappers, with n being the respected window size of the connection. The wrappers will be reused. This should reduce memory allocation overhead, fragmentation, and processing time needed fairly well. There was also some garbage in the RDP round trip time estimation and some stupid processing in the state machine. There was also a chance that on opening an RDP connection the nipc.library on the passive side of the open could free an nipc buffer twice if no suitable port to connect to existed. nipc.library is now at 40.61. - I am really not sure what kind of problem we have with nipc right now. For testing I added some more paranoia checks for things that should never happen. There was one case where a ReplyTransaction() could mess up an internal counter. But this case would have only been triggered if there wasn't a free signal bit. Very unlikely and impossible with EFS. I doubt that it is actually the problem. The triggered error 531 is significant for a connection that got shut down unexpectedly. This can happen only on _very_ severe network failure. Highly unlikely. I redid the library setup code to make debugging and maintenance easier. Hmm. The work of the setup code I could have avoided if I had known how buggy the QuickNetS2.device 2.3 is. Oh well, without a matching test setup and reproducible results one is just fiddling around sometimes :-(. I still have to investigate the sudden appearance of error 531. To help with this, I added even more paranoia checks to the transaction and entity management code. nipc.library is now at 40.62. - The IP fragmentation code was buggy. It didn't handle the header length well and could possibly confuse things depending on the packet length. My previous checks of the fragmentation code did not take the packet length into account that well. I tried to do it right this time, though it is tricky stuff. I wonder what kind of MTU will break things again :-(. The reassembly code wasn't that great either. I added a few sanity checks that should help find further problems. I had also introduced semaphore deadlock potential into ReplyTransaction() in 40.60 which blocked nipc on random occasion. This was probably the cause for dying connections. A semaphore stayed locked where it should have been unlocked temporarily. Hmm. I really need to get the external IP/ICMP interface done if only to be able to test this stuff without major setup work. nipc.library is now at 40.63. - On reassembly of fragmented packets, the length of the resulting packet was calculated from the size of the fragment nipc buffers, not from the sizes set in the packet headers. These can well differ with e.g. the A2065 where it somehow seems that the minimum data link buffer size returned is 50 bytes for some reason unknown to the SANA specs. Depending on the amount of data transferred this really confused packet reassembly and resulted in garbage data for the registered IP protocols. I tested this (finally) with the a2065.device and noticed that both the C= a2065.device 2.16 and the inet version 3.0 (which I happened to have access to at the time) have deadly CloseDevice() code. As I always run enforcer and mungwall this stuff is a nuisance at best. I think I need to create an HWG a2065.device. Hmpfh. nipc.library is now at 40.64. - I had an optimization in the reassembly code that rearranged the order of the fragment list to reduce seek times. Somehow this didn't work right. So I took it out for now. I'll have to investigate this problem, though. nipc.library is now at 40.65. - The modification to the nipc buffer size for incoming packets with a buffer that is bigger than the actual packet is now done in a more logical place. This means that I don't have to check for data sizes later. I also left in a paranoia alert and a debugging kprintf. They should tell us about problems. Hopefully all of this finally fixes the 531 errors. nipc.library is now at 40.67. - More nipc changes. The S2R2 packet filter support did not take the new protocol registering scheme into account. It should now react to all registered IP protocols. Previously, it only knew about ICMP, RDP, and UDP. Using packet filtering has subtle consequences for very advanced setups. Only those packets will be handled that nipc understands itself. This means that you can't use gateway functionality in a mixed setup with packet filtering because "unknown" IP won't be !! accepted, handled or routed at all. Net result: For IP gateways, !! turn off packet filtering. !! The gateway flag is finally evaluated inside nipc IP routing. !! Basically, this means that Envoy based machines will only !! exhibit gateway functionality in IP routing now, if they are !! configured as gateway via Network Configuration. You have to !! specifically TURN ON gateway functionality compared to !! previous versions. If your machine isn't a gateway, i.e. if !! it doesn't have to forward packets for other machines on !! different physical networks, DON'T use it as gateway. IP options were not processed in the copy that was sent out, but in the original packet. This could have messed up things not only for broadcasts. Local IP packets were not necessarily handled correctly. Even the complete S2R2 configuration can be updated without a reboot now. On a configuration change, nipc.library will shut down all the devices and reopen those found in the configuration. Note that this also (obviously) means a loss of any additional routes you set. In any case it should no longer be needed to reboot an Amiga with Envoy now. This might mean that you better upgrade to a2065.device 3.2 with my CloseDevice() fixes as the old a2065.device doesn't shut down correctly. Some SANA code used a questionable setup of device requests. This should be fixed now. Note that I left in a single paranoia kprintf at the moment. It will be activated if the calculated packet size can't be successfully matched to the buffer. This should never ever happen anymore, but who knows. !! You should better update nipc.library on all the machines !! now. There are incompatibilities. nipc.library is now at 40.68. - It seems that EnvoyFileSystem is now ok. I took out the kprintf calls and bumped the version. EnvoyFileSystem is now at 40.59. - If you had a broken volume with an empty name on the server, this name was propagated through to the client for RMS imports. As it is not that easy to access a *specific* volume with a name of ":", volumes without a name string will now be called "Unnamed". filesystem.service is now at 40.55. - Ouch. I had messed up ResolveName() in nipc for named local queries. nipc crashed really bad if you specified the local host name. nipc.library is now at 40.69. - Blush. My smart grep for active kprintfs failed. I overlooked one in EnvoyFileSystem. It is removed (hopefully :^) now. EnvoyFileSystem is now at 40.60. - As you all know, envoyprint.device basically sucked. I thought that I could fix it, but I was wrong. I redid it in C now. It is not compatible to the original 2.0 envoyprint.device, it should be compatible to the intermediate beta assembler envoyprint.device, and it should be good enough for the new printing system (if it ever sees the light of day). With a little bit of luck, I won't ever have to touch it again except for bug fixes. envoyprint.device is now at 40.8. - The print spooler was also pretty messed up. I repaired the remaining problems like left over spool files on timeouts. If the printer won't accept any data, the spooler is capable of aborting a job by asking the user. Currently, this message is still in english only as this code will disappear anyway, once the new spooler is done. So except for a few bug fixes, this spooler is not that different from V40.8. I intend to release this patched up printing system as a free patch on Aminet as the 2.0 printing system is very !! broken. Please test the current envoyprint.device and the !! printspool.service in a bare 2.0 setup. Tell me about !! conflicts with the old config tools and/or other parts !! of Envoy 2.0. PLEASE, PLEASE, PLEASE! printspool.service is now at 40.9. - The memory pool handling in nipc no longer depends on nipcbase contents. This simplifies maintenance a little bit. I reworked the library startup. Now there is no need any longer to maintain both an internal asm and C include file for the nipc base. Finally, the asm include could be retired. This solves one big maintenance headache for good. The remaining kprintf got commented out, too. On 32 bit machines nipc could be marginally faster with entity handling now. I fixed 32 bit structure alignment in one place internally that I overlooked earlier. nipc.library is now at 40.70. - A fix to both the EFS client and server. ACTION_CHANGE_MODE handling was really, really very broken. The EFS server connected comment and file name on doing ExAll emulation. It would create locks and file handles even if it did not have enough memory to remember them. There wasn't even a basic consistency check on passed in lock or filehandle values. For now I added major checking code that can be disabled once we are sure again that nipc or the client don't mess up the data passed to the server. Also there is new debugging timeout magic added to the server. If you break it with CTRL-D or if you change the configuration, it will contact all clients on the next heartbeat and disconnect those that don't answer. Together with the private magic CTRL-F to shut down the server, this should make hunting for leftover locks and filehandles a lot easier! filesystem.service is now at 40.57. - The client should name the error number now if it encounters an unknown nipc error on a connection failure. EnvoyFileSystem is now at 40.61. - GetHostName() will fail now if the name doesn't fit into the passed buffer. The resolver miscalculated a buffer length by one when querying the host name. Actually, the resolver did a few messy things and used internal data without semaphore protection. It should do the right thing now. And it shouldn't crash on 68K machines any longer with misaligned query data. As the resolver is used on reconnects, this might explain some of the spurious problems we had. Some work spent on the S2R2 low level code. It used different types of IORequests for a single device. The code should behave much more straightforward now which should help debugging future problems. Ralph might like this one again. His observation that something very bad must have happened during the change 40.67->40.68 was right. I never doubted it. It took me quite a while to figure out the problem though. It was an obvious bug that should have jumped in my face the minute I looked at the code. Under certain circumstances the packet filtering code caused a semaphore to be used. It is obviously not wise to use semaphores in interrupts. I did not realize it because there is LOTS of valid code using semaphores and I didn't notice the interrupt dependency. Ouch. The workaround means that the packet filtering code will no longer filter unneeded packets all the time. Sometimes it will let unknown packets through. Actually, I am not too fond of the packet filtering idea in S2R2 anyway. A complex protocol stack like nipc will be able to support arbitrary protocols, which means that usually some protocol list must be scanned to find out which packets to filter. Obviously some kind of arbitration is necessary here in the filtering code and most certainly I don't think that Disable() is appropriate on the protocol stack level to scan a list. This means that the whole packet filtering idea is flawed in terms of design IMHO as it can be used only for dumb stacks handling a known simple set of protocols. Obviously I could rewrite the code to keep a somewhat simple static array of packet types to be scanned (in addition to the list) that is replaced only during a Disable() when a protocol is registered or freed, but I really feel bad about that. I don't like Disable() even for a simple memory update. If you want to convince me of doing this because you think the filtering benefit is worth it, talk to me. nipc.library is now at 40.73. - The UDP checksum algorithm could produce a "no checksum" result for certain packet types. UDP also wouldn't close all open connections on shutdown which was not very black box at all. nipc.library will start throwing ICMP messages around now. I also added basic general IP based protocol support. This means that anyone can set up and register any IP based protocol with nipc now and take advantage of the complete IP layer. I can almost completely black box the internal protocols now and kill global interactions. Great! The "only" thing I still have to do now to do debugging on the packet level is to write a monitor protocol, simply displaying all the IP packets that are coming in. I still haven't decided on a SNMP interface though. This is very tricky stuff. It would sure help to have this though. At this time, nipc will do a kprintf for every ICMP message requested. Actually ICMP messages shouldn't be sent that often and right now it may be a good indication if we have any problems. One ICMP test I did was to deactivate a device packets were routed over with Network Configuration while a transfer was active. nipc took it well and started to use ICMP. I love dynamic configuration. It is interesting to observe how nipc gets more and more complex while getting less and less complicated at the same time. Well, it is getting bigger. nipc.library is now at 40.75. - ICMP had a wrong protocol number as I mistyped an identifier. So nipc wouldn't recognize any ICMP messages. IP fragments are no longer handled via the S2R2 device structures. They are now an integral part of the IP layer. Even if a packet definitely could not be reassembled, the reassembly code would loop through all the fragments. Raised the fragment timeout to 15 seconds. Comer uses 60 in his simple example code, but he also uses limited buffering. I don't want to flood nipc. The RDP code now doubles the timeout on packet retries with an upper limit of currently 20 seconds. There was a tiny hole in FindEntity(). With just the right timing, it wouldn't find an entity that was perfectly well and alive. RDP will no longer kill a connection if it was unable to send data due to lack of memory. It is much less expensive to get more resources again than to reestablish a connection. And memory is needed to do the latter anyway. RDP used to rely on IP fragmentation for fast networking HW by sending packets of about 3*MTU. As loss of a single IP packet means retransmission of 3 IP packets then due to the loss of the respective RDP datagram, I took this "feature" out. Fragmentation is expensive in terms of memory usage and CPU load anyway as buffers need to be copied. RDP will no longer use fragmentation! The RDP round trip time and connection speed estimation was garbage. This may be part of the cause why sometimes connections got lost. The S2R2 code will no longer accept devices with a MTU value less than 100 or a BPS value less than 1000. These are silly devices where quite a few things wouldn't work anyway. The transaction and RDP timeout setup was garbage, too. It now uses some correctly calculated values that actually have some meaning in real life. The old code screwed up timeout handling to no end, It even generated negative timeouts. The new code is basically what TCP does. It is modified for differences of the RDP implementation, though. We use Karn's algorithm when the connection is active. For establishing a connection, there is a fixed timeout and a few retries. The new thing is that RDP tries to always do a correct roundtrip time estimate. The result is that the transaction timeouts (which have always been adjusted to compensate for the transmission delays) should now finally be accurate. If the load on the net increases, nipc should no longer fiddle around with roundtrip times that were calculated on connection startup only. We have an adaptive timeout in RDP now that should make reconnects a lot less common. This is very hard to test for me though. I'd need a setup that would emulate a long delay on the cable. Tricky to do in SW. Maybe someone using Envoy with a dial up connection can shed some light on the results? These extra computations may slow down Envoy on slow machines. On an A3k/25-A4k/WE040/40 Ethernet setup, I can't see any noticable diskspeed difference. On packet loss you should still see a few kprintf's. nipc.library is now at 40.76. - If you passed an ACTION_CREATE_DIR with a ZERO baselock, an empty name, and just the right type of garbage in dp_Arg3 to the EFS client, it would do a certain amount of ACTION_LOCATE_OBJECT specific processing. This in result could produce an internal lock that would not make any sense. EnvoyFileSystem is now at 40.62. - I increased the lock and filehandle check level in the filesystem server again. It will try to post recoverable alerts now, if it encounters bad values. Maybe this helps locating these spurious server crashes. filesystem.service is now at 40.58. - Owner and Group will no longer print an error message twice or return ok for errors. Owner and Group are now at 40.3. - When reworking the user/group packets in the EFS server, I messed up some IoErr() values. Things should be back to normal now. filesystem.service is now at 40.59. - Fixed up the Service docs and added a new Tag SVCAttrs_FullService to be able to tell if a service supports SetServiceAttrsA() and AttemptShutdown(). The recompiled services.library is now at 40.8. - As of this moment I will no longer support assembly includes for Envoy. In the quest for portability, assembly includes simply will get in the way. They are also a dangerous maintenance hassle that already got in the way a few times. - After a lot of thinking I found out that the internal buffer management in nipc had a few holes that required a major check of all the involved code. There were some strange things to fix and it caused me some grief to rework this, but it should be stable again now. I am not sure if it is the a2065.device yet, but I had the effect that the very first packet written out to the device after a reload of nipc.library was lost. This caused a slow RDP startup. I worked around this for now by simply sending the RDP startup packet for a connection twice. This doesn't hurt RDP and helps startup performance by a few seconds even if a driver has a problem. Obviously the driver causing this should be fixed though. ICMP should process redirect messages now. Tricky to test. The UDP interface has been reworked and is going public about now. All of the buffer stuff has caused a major source change. Please test for memory leaks and mungwall problems! nipc.library is now at 40.77. - Major 2065.device rework. It did some very very nasty things. I hope I got them fixed now. As a side effect, interrupt load may have decreased. PLEASE TEST THIS WITH MULTIPLE PROTOCOL STACKS! This internal version is now called 3.5 to avoid version problems with the Interworks version 3.2. It supports the New Style Device standard now. - nipc should no longer rely on initial notification for its prefs file. Tss. Is there is still a fs around not supporting notification? :^) The sfd file for nipc is fairly complex by now due to the enw and still private function calls. It turned out that the SAS/C SLINK can only handle simple FD files, so nipc will no longer use SLINK, but generate a vector table via a simple ANSI C tool "makevectors" now. This is much more portable anyway. nipc.library is now at 40.78. - The EFS server did not set the return codes for packets correctly for ACTION_END and ACTION_FREE_LOCK. Actually it did not set quite a few return codes correctly, related to lock and file handle checking. I must have been drunk while writing that code. This should have fixed the WB copy "Required arg missing" problem for good. It is also a major rework that needs lots of testing. I also fixed a few bugs with packet arguments that I introduced for a future V43 OS (which may never come). The server will also make a lot less !! assumptions about FileHandle internals now. The User/Group ID !! conversion packets have consistent return values now, even !! though they are a little strange for a conversion to an id. I decided that probably nothing uses these packets except Envoy itself, so I could safely fix them. #define ACTION_Dummy 20000 // res1: ID if res2 == 0; res1: invalid if res2 != 0 (res2 == error indicator) #define ACTION_USERNAME_TO_UID (ACTION_Dummy+0) #define ACTION_GROUPNAME_TO_GID (ACTION_Dummy+1) // res1: DOS bool, res2: error if res1 == DOSFALSE #define ACTION_UID_TO_USERINFO (ACTION_Dummy+2) #define ACTION_GID_TO_GROUPINFO (ACTION_Dummy+3) Don't try to define new packets around these values or any other values. These packet numbers are "old" C= numbers that finally have a usable definition. They are not an invention by IAM. There also was a subtle bug in ACTION_RENAME handling. If dp_Arg3 was ZERO, a wrong volume descriptor might have been used to find the correct base lock. As the whole return value system has been reworked, it may be extremely wise to do some decent testing! Notification for file creation did only work for secure mounts well. The securoity checks for file creation/open had holes. You could access a file even if you did not have access permission for its immediate parent directory. Security for ACTION_PARENT didn't really work at all. It was possible to lock directories without E permission. It checked the source lock instead of the result. ACTION_SET_COMMENT/DATE checked the directory lock, not the object they were accessing. ACTION_FH_FROM_LOCK accessed the lock after creating the filehandle. For this packet I am not completely sure how to handle security. In fact the whole security handling of many packets is debatable. What should be checked and why in each case? There are grey areas IMHO or I am confused. The big problem is directory permissions. How should they be treated. What e.g. about parent permissions? Afterall, AmigaOS is not Unix. What do you think? This is the time to voice your opinions and to look hard at security. filesystem.service is now at 40.61. - Finally, the EFS server should shut down pending mounts correctly for clients that have been turned off correctly. During the check, the server may pause for a few seconds. This is unlikely to change, but persistent probing of dead clients which bogged down the server should no longer occur. filesystem.service is now at 40.62. - Owner and Group support the consistent UID/GID conversion now. Previously they wouldn't have handled a zero Id. Owner and Group are now at 40.4. !! - A general note: Now that nipc generates ICMP messages, it is !! very unwise to use it along any TCP/IP stack with the same !! IP/ARP packet types. The stacks may confuse each other. Just !! bump the Envoy types by one if you are using TCP/IP on the !! same line. - There was a failure path in the EFS server where the ACTION_SEEK primary error result would not have been set to -1. filesystem.service is now at 40.63. - The EFS client returned wrong error codes for C:Lock'ed mounts for certain packets. Error handling should be safer here now as it is unified in the client. ACTION_DISK_INFO will no longer fail, even if the network is down or goes down during the request. If you find a failing ACTION_DISK_INFO, scream at me with a bug report. In case the network is down, a fake InfoData structure will be filled with ID_VALIDATING, ID_NO_DISK_IN_DRIVE. id_NumSoftErrors will contain the number !! of reconnects for this mount. This should fix the temporary !! WB lockups caused by lost server connects. Note that an !! ACTION_DISK_INFO will no longer trigger a reconnect! This is intentional. The client used to complain on unconnected locks and file handles left over from a previous connection. Typically, this didn't occur as all of them were reconnected right after the connection was reestablished. It could happen though if some part of the reconnect actions failed for whatever reason. The client will now try to reconnect these handles once again before complaining on them. Cleaned up and unified some packet handling. EnvoyFileSystem is now at 40.63. - nipc had a hole in its shutdown code that could lead to unexpected crashes. In entity handling, there was a semaphore lock messup which could have caused a deadlock for unreliable connections. The RDP timeout values and handling were not exactly great. UDP had a deadly problem with any ICMP packets due to two missing lines of code. In ICMP handling, a break statement was missing, even though that bug didn't have any adverse consequences at all. ICMP echo didn't. If someone called DeleteEntity() for an Entity that had been found by some remote site, the remote site was never notified that the Entity got shut down. Actually, to be correct, the problem was that the Entity was always marked for a delayed delete without even trying a shut down. This means that clients could "hang" on long dead entities for a while even !! though the HW was ok. MAJOR RDP REWORK. As it turned out RDP !! still wasn't RFC conforming at all. This release of nipc is !! most likely completely incompatible to previous versions. Especially the connection startup was messy. When shutting down, nipc will complain with a recoverable alert now if someone forgot to LoseEntity() his local stuff. On the way I produced and fixed a few deadlock bugs. It would be great if I could do RDP on a different context and have transaction handling run on its own context. I would only pass messages with data then and I wouldn't have those semaphore interactions. Unfortunately, doing it like this is expensive due to context switching. It seems that nipc and RDP are reliable again. I have to write this at this very moment while I copy quite some amount of data from the A4kT to the A3k to trigger any bug again. If nothing shows up, this may be a candidate for beta testing again. Entity shutdown via either DeleteEntity() or LoseEntity() had a few holes. It should be safe now. nipc.library is now at 40.80. - If you find any typos in the notes above, it is most likely the fault of the female german person tickling me here in front of my machines. - With the major EFS server changes, I broke ACTION_FH_FROM_LOCK. A line of code was missing. The filesystem.service is now at 40.64. - The client had a problem with delayed root locks. On resolving them, it could attribute them to the wrong volume if a reconnect occurred in the meantime. In low memory situations, the client could have returned very strange results on ExAll()'s. A general problem will remain for people exporting RAM:. If the server reboots, it will create a new RAM: with a new volume date. This looks like a different volume to the client, so the client will never be able to reestablish that mount correctly as expected when you have pending delayed root locks or obtain a delayed root lock after the reboot before the client noticed it. Nothing I can do about this. The simple fix is not to export RAM: or any other "volatile" volume for anything of importance if server reboots are likely. EnvoyFileSystem is now at 40.64. - nipc.library supports S2R3 now for incoming data. At this time I decided not to put in code for outgoing data, as the outgoing data buffers can have a format that may be quite warped. The overhead to decide on the buffer format would currently be excessive IMHO. I may add a simple check later when it turns out that the current stuff works well. The new event system didn't work at all. I was too hasty in a few places when writing the code. It should be ok now. Woah! While doing the changes for the new internal RDP interface in transaction handling, a line of code got lost. The trans_Error field was never set up for returning transactions anymore. Which means that _everything_ was returned as successful that didn't fail locally. This shoudl also fix the users/groups editors "waiting" forever when used with an AccountsServer. They simply collected one user over and over and ate up memory and CPU time. You are asking why the rest of the system worked fairly well anyway? It seems that networks and the EFS server are more stable than we think they are. There was also a problem in setting up incoming transactions. trans_RespDataActual wasn't set to 0 (which caused extra return traffic on the reply) and the trans_RespDataLength wasn't correct for magic "in place" transactions where request and response share the same buffer. I am using this beta now to test the upcoming SAS/C 6.57 patch, too. A few warnings 317 hit me which was a good thing. A line of code was missing that messed up correct subnet matching. nipc.library is now at 40.82. - Cough, cough. trans_RespDataActual may not be set to 0. There is the silent assumption inside nipc and user code that the buffers will be transmitted completely if the Actual values are not touched by the user. In effect, you are reducing the amount of transmitted data if you set the Actual values to less than the respective buffer size. Default has and will now always be full buffer size. This is also documented in the autodocs now. Another lesson learned the hard way. nipc.library is now at 40.83. - EnvoyFileSystem had a small hole. If a reconnect happened while an ExAll()/ExNext() was in progress, the server would get an invalid lock identifier which could have really confused it and the client would abort early. EnvoyFileSystem is now at 40.65. - EnvoyFileSystem had a bigger hole, too. If an internal ExAll()/ExNext() was in progress and some error happened, the original packet would never get replied to. This, and a stupid variable usage bug that turned up due to the fix in 40.65 made examine stuff really unsafe. EnvoyFileSystem is now at 40.66. - Recent work on nipc.library made it crash on plain 68000 machines due to a violation of data alignment restrictions. I also added some minor caching for IORequests which should help performance. I also added a kprintf for any SANA I/O error that I get for now. This should help debug the backup freeze problem. nipc.library is now at 40.85. - Major overhaul of envoy.library in preparation for quite a few necessary tool changes. Stack usage and GUI compatibility need to be checked! envoy.library is now at 43.2. - Again RDP problems. Not with data management, but with semaphore locking issues. We had several unprotected areas. This in turn could have affected transferred data. Also RDP should no longer try to work with closed connections that much. A major RDP interface rework has been done to fix these problems. Quite a few LOC have been shuffled around without really affecting the protocol implementation itself. MAJOR MAGIC INSIDE. Please let me know about deadlocks and efficiency changes. The icmp and S2 debugging kprintf's are still in there. nipc.library is now at 40.86. - Found some problems in the requester layout code and added some gadtools handling functionality that I need for easier GUI creation. Now this stuff doesn't have to be duplicated all over the place. envoy.library is now at 43.3. - The Accounts Server had some problems. Group management could mess up the user id of the admin user. Finally it shouldn't be possible any longer to kill the last admin. It shouldn't be possible any longer to have duplicate group or user names. Accounts Manager is now at 37.19. - The major changes in envoy.library caused two things to be overlooked. The requesters didn't open active anymore and had no close gadget. The GUI tries to be smarter than Intuition now about window borders to be compatible to Intuition hacks. envoy.library is now at 43.4. - More changes to the GUI code. There were bugs in unused code parts for calculating sizes. It didn't get along well with font setups that gave reasonable results but were smaller than topaz 8 in either direction. I also unified lots of code in the requesters which did basically the same thing. This code should be darn smart about the layout now. Hopefully. UGREQ_OptimWindow was not handled. Major rework inside to make the GUI code more accessible to the other Envoy tools. The envoy.library is now at 43.6. - There was a deadlock in the RDP locking code in nipc.library. I revisited the whole locking scheme. I should be on the right track now. nipc.library is now at 40.87. - Found some more problems in a2065.device. a2065.device is now at 3.7. - Found some more problems in a2060.device. These were stupid to the point of embarrassment, though they didn't affect SANA2 use of the device. a2060.device is now at 40.9. - The Users preferences use the new GUI engine now. Users is now at 37.20. - The Group preferences use the new GUI engine now. They should also handle the group list correctly now for a late login. Groups is now at 37.16. - envoy.library needed a further enhancement to support the new Services Configuration. The default pubscreen is now inherited from a specified optim window if no other screen is specified. This should fix general pub screen behaviour for most cases. A ScreenToFront() and WindowToFront() is done if appropriate, too. envoy.library is now at 43.8. - Reworked Services Configuration to use the new GUI layout code. Services Configuration is now at 37.16. - All new Filesystem Imports. Same functionality, better looks. Exports is a little more tricky to do. Filesystem Imports is now at 40.18. - Due to lousy autodocs and my acceptance of the word as is, some code in envoy.library used a V39 only graphics.library function. This and a couple of gadget size calculations are fixed now. envoy.library is now at 43.10. - nipc.library had a ReleaseSemaphore call that shouldn't have been there. nipc.library is now at 40.88. - Filesystem Imports no longer tells us about successful connections. We can see that anyway and are told about errors. Filesystem Imports is now at 40.19. - Filesystem Imports now has a NOSECURITY tooltype and command line option. This will suppress the login requester and makes maintenance of networks without security easier. Currently, for mounts that you want to do once in a while that should not be automounted, create a permanent mount and drag the created mount icon from DOSDrivers or (WBStartup for 2.0 systems) to your favourite storage place. A single click will give you the needed mount then. FSI is at 40.20. - A long overdue change to nipc.library was needed to support envoy.library better. Frankly, this got on my nerves for a long, long time. Now I fixed it. NIPCInquiryA() can now be aborted early in a fairly decent way. In anticipation of a general feature freeze, the version has been bumped. nipc.library is now at 43.1. - The envoy.library host requester no longer waits. Yeah! Well, actually it waits 5 instead of 2 seconds now for a response, but you don't have to wait. Some enhancements to the GUI code in anticipation of the needs for reworking NIPC Configuration. The login request will fetch ENV:USERNAME if available and no user name has been given. If a user name is there but no password, the pw will be activated for entry. envoy.library is now at 43.12 and requires nipc.library V43. - Filesystem Imports is done. This was a tricky one, though NIPC Configuration will be very tricky compared to this one. !! The prefs format and the default file name have changed. Do a !! "Filesystem Exports FROM ENV:Envoy/efs.config SAVE" !! This should convert the data to the new format. Note that you !! also need an updated filesystem.service to use this! Filesystem Exports is now at 40.21. - The new prefs code fell victim to a intuition/gadtools refresh bug. It is unwise to fiddle around with gadtools gadgets _during_ a refresh as it turns out. The code did pretty much exactly that in a nonobvious way. Somewhere, there is a deadlock possibility. I took this opportunity to bump the versions. Filesystem Imports, Filesystem Exports, and Services Configuration are now at 43.1. !! - filesystem.service now supports the new prefs file. To avoid !! support problems, the old file is no longer read. !! filesystem.service is now at 43.1. - Major nipc.library rework. There were still serious problems in the locking scheme. I really hate this. ~120KB of sources are affected and have to be handled each time I touch any of that code. I redesigned the entity shutdown code to be a lot less warped. Previously, there were _tons_ of nested semaphore calls on multiple contexts for all the entity handling. Now we can count them in kilograms and I defused even more explosive code. Incidentally, this rework seems to have made nipc noticably faster. Ha, as if this would make it more stable :-/. I put in more paranoia alerts. Let me know if you encounter any of them! ALL THIS NEEDS ***HEAVY*** TESTING! I also spent about two days tracing and debugging RDP packets to be sure that it works as expected. I put in detection code to find and kill dead passive ends of a connection and killed a paranoid call that resetted a conenction twice for no reason. There is no active probe by nipc to test potentially dead active ends because this would really mess up dial up on demand. I heard that at least one person is trying to do that. Oh well, I originally planned to get Network Configuration in shape this weekend. BTW, this entry crosses the 2k line in my history file! nipc.library is now at 43.3. - I broke GetHostName() for 43.3. Locking was in the wrong place. Well, actually, GetHostName() had another flaw that I didn't cause, too. I won't tell. nipc.library is now at 43.4. - I broke even more. Rework of FindEntity(). Fix of the dead connection detection. Clarification to the WaitTransaction() autodoc. Useless paranoia code for broken BeginTransaction() calls replaced with dead end alert. nipc.library is now at 43.6. - envoy.library missed some locking calls. For refresh support of parent windows, I reactivated the stone age (incomplete and broken!) callback support in an ASL like manner. envoy.library is now at 43.14. - Services Configuration displayed trash when removing the last service. Services Configuration is now at 43.2. - Filesystem Imports now uses a mode cycle gadget. It also supports a new mode "Storage", which mounts the drive and puts a permanent icon into DEVS:Storage/DOSDrivers. Catalog update required. "Temporary" as default choice is intentional. It also refreshes its window while the envoy.library requests are open. Better now, Olaf? Filesystem Imports is now at 43.3. - I think I stumbled over the "no write after open" problem with the client during testing. It was not reproducible though. I don't know yet what it may be or if it is the client or some side effect, but I found very strange error messages in the client along the way. The client has been updated to put out better error messages for some connection problems, which may help locating problems. Previously it complained e.g. that the server refused data when that very data didn't even leave the client due to nipc connection problems. A catalog update is required. EnvoyFileSystem is now at 43.1. - Users was really broken. You could create users with an empty name, a checkbox gadget was internally used as listview due to a wrong define, it reconnected to the server pretty much all the time, and refresh was broken. Users is now at 43.1. - Groups pretty much had the same problems as Users. :-/ Both Groups and Users could be really cleaned up big time inside, as it is still lots of old code in the new prefs wrapper. This does not seem to be the time to do this, though. Groups is now at 43.1. - Angela found a bug in Filesystem Imports while clicking around not just a little bit. For temporary mounts, a trashed buffer would be used to lock the volume. Filesystem Imports is now at 43.4. - Angela found a few more bugs. EnvoyFileSystem did not take ACTION_INHIBIT well. More precisely, it didn't handle other packets well while inhibited. I did not check it with the RCS archives, but I suspect a source line got lost during editing sometime ago. The EFS client also did not take ACTION_DIE well with ACTION_INHIBIT being active. The Info results if the exported _device_ is inhibited now make more sense. Note that ACTION_INHIBIT in the EFS client is for debugging, not for using a disk editor. EnvoyFileSystem is now at 43.3. - Angela found another bug. Filesystem Exports did not refresh gadgets correctly when restoring the last saved prefs. - Filesystem Exports did not refresh the main window when the user requester was active. Filesystem Exports is now at 43.3. - I took out the remaining kprintf in nipc.library. I also made two internal routing functions public due to a very reasonable request by one knowledgeable Envoy user. nipc.library is now at 43.7. - Another one. Users did very strange things with the gadgets up to the point of not doing with the user data what it should have. Angela pestered me about the awful password handling. This led to me giving in and changing both Users and envoy.library to support a general password change requester. !! If a user _needs_ a password, s/he must chose one of at least !! six characters now that is not equal to the previous one. Users relies on at least envoy.library 43.15 now. This isn't a problem as previous V43 versions are not publically released anyway. Users is now at 43.2. - envoy.library changed again. Quite some rework inside to support the new password requester. The new password requester also optionally checks that a password entered is >=6 characters long and not equal to the old password. I wish I would finally get around to do something about Network Configuration, which may require more changes to envoy.library. envoy.library is now at 43.15. - In preparation for install changes, the Accounts Manager needed some rework. It will always use the next free user/group id now when allocating a user or group. While this could cause "stale" id's to be used, id's won't run out. A little unixish behaviour here. Accounts Manager is now at 43.1. - Services Configuration got new "majik" options now for me to be able to kill the little BuildSMPrefs hack. The CFGFILE and CFGLINE options take similar arguments compared to BuildSMPrefs, but can do more. With CFGLINE, you can specify a single configuration line as listed below. With CFGFILE, you can handle a whole bunch of them, including empty lines. Note: To discriminate between different lines, the first argument of each template must not be moved from its place or aliased. Other than that, the templates are pretty much self explaining. There is hardly any error checking, as THIS STUFF IS NOT FOR CASUAL USE! "ClearPrefs/S" "Service/K/A,PathName,Active/S,Inactive/S,Remove/S" Services Configuration could have lost memory to disk objects previously. It also allowed duplicate entries and handled the entries on the services list according to the current moon phase. Services Configuration is now at 43.3. - I added the CFGFILE and CFGLINE options to Network Configuration, too. Now I am able to rework the installation a little bit. "=Dummy" as first arguments are dummies for template recognition. THIS STUFF IS NOT FOR CASUAL USE! "ClearPrefs/S" "HostInfo/K/A,RealmName/K,RealmIP/K,Owner/K" "RealmInfo=Dummy/S,RealmName/K,RealmIP/K,UseRealmServer/S," "NoUseRealmServer/S,RealmServer/S,NoRealmServer/S" "FlagConfig=Dummy/S,Owner/K,Gateway/S,NoGateway/S" "DevInfo/K/A,IPAddr,IPType/N,ARPType/N,SubMask/K," "Unit/K/N,Filter/S,NoFilter/S,Active/S,Inactive/S,Remove/S," "CheckUnit/S,HardAddr/K," "NoHardAddr/S,NoIPType/S,NoARPType/S,NoSubMask/S" "RouteInfo=Destination/K/A,Gateway,HopCount/N,Remove/S" "LocRealm/K/A,RealmAddr,Remove/S" "RemRealm/K/A,Server,Remove/S" Note that what you are getting here is an intermediate Network Configuration that still has the old GUI but tons and tons of preparations for it inside. Without it, I can't send out a full archive, though. Network Configuration is now at 43.1. - Woah. Services Manager fiddled directly with the Library base of services.library. it also had some holes allowing for messy fiddling with the services lst. Services Manager needs services.library V43 and is now at 43.1. - services.library had similar holes and needed some more magic to support the manager. I also cleaned up the includes a bit. services.library is now at 43.1. - Some basic rework for the install script. It uses some features of the V43 installer now, does not need the prefs hacks any longer, updates the EFS config file if needed and has some minor improvements to get started somewhere. All the docs are still "2.0". I probably have to kill the amoksana stuff if I can't get a fixed device driver. :-/ It *should* already allow for a clean update from 2.0 or previous envoy versions and a new installation. Let me know what happens for you. - nipc.library uses some of the internal services.library magic, too. It now depends on V43 of services.library. nipc.library is now at 43.8. - More rework to the installation. Still no in depth tests or improvements, but the basic bugs I introduced should be squashed now. Sometimes I wish I had reworked Installer at the time to support on demand include files. If it just hadn't been that messy... :-/ - The central IDCMP handling loop in envoy.library kept on processing the currently available messages on an end request. This overwrote state variables and could cause it not to react to, e.g., an OK click. envoy.library is now at 43.16. - The problem with IOUsedTwice paranoia alerts in nipc should now be fixed. They came up when a new transaction was replied to (due to a transmission error) before being sent completely. Now, the transaction is only added to the async management when the transfer has completed. This is protected code to make sure that an immediate reply is not lost. nipc.library is now at 43.9. - EnvoyFileSystem did not report write protection for locally locked volumes correctly. EnvoyFileSystem is now at 43.4. - I got a bug report about C:Copy reporting filenames several times when copying files from a remote CacheCDFS mount. I still think that CacheCDFS may mess up the ExNext chain here as I take great care to preserve the FIB well. Nevertheless, I investigated the ExFOO stuff in the filesystem.service and found less than great handling of errors and the magic .backdrop/Disk.info examination. I reworked this to be a lot better now. Also, the first ExNext after an Examine of the mounted "root" should now behave according to spec, even though it is a little bit slower than it used to be. filesystem.service is now at 43.2. - SH**, D*****! On V37 systems, ng_TextAttr must remain valid and constant throughout the lifetime of the gadget or you will get very strange rendering for some gadtools gadgets! Another one of those untold stories! While comparatively easy to work around even with font sensitivity, this affects quite some amount of code. - Filesystem Imports preserves the mono TextAttr now. It is now at 43.5. - Filesystem Exports preserves the mono TextAttr now. It is now at 43.4. - Services Configuration preserves the mono TextAttr now. It is now at 43.4. - I broke ExamineFH with the previous rework of the EFS server. It would also return a user reject for a non existent mount. Now it should tell you that there is no mount instead. I think I found the cause for the "stale" lock/fh paranoia alerts. Very complex and heavy magic. As I could never reproduce them myself, I added another magic check to confirm my idea on this before blindly adding "fixes". Let my know about the next batch of Alerts and sushi output that you get. I also found a few less than safe checks that I fixed. On the way I reworked the library startup code to behave better. I forgot to tell you that you cannot any longer export Envoy mounts to avoid circular FS packet handling deadlocks. filesystem.service is now at 43.3. - Only a user with Admin rights can now use Filesystem Exports. Filesystem Exports is now at 43.5. - EnvoyFileSystem messed with the connection identification on an ACTION_DISK_INFO while the network was down or an error occurred. This is not a good idea as a reconnect will be triggered when needed automatically. There is no need to arbitrarily try to force one. Also, a mount with >65535 reconnects should behave correctly now :^). There was a problem with locating a correct volume node after disk insertion in case the volume node name had been modified to avoid name collisions. The client will now use the internally kept "true" name to identify volume names. Locks and FH's no longer require two memory allocations each. DupLock() of an internal fake lock or a 0 lock will now also try to create a fake lock before contacting the server. This should help GetDeviceProc() based applications. ExNext() related Zombie locks could be freed without freeing the attached reconnect info. EnvoyFileSystem is now at 43.7. - filesystem.service had a messy way of handling the baselock of a mount. It could do diskchange loops on local Envoy mounts and possibly deadlock. This should be fixed now. I also added quite a few DEBUGGING kprintfs whenever a volume is set up or changed. There are also new paranoia checks inside to report on memory trashing of the internal resource lists for locks and file handles. This should help to identify the cause for bad locks. This is a debugging release. It should also ignore old uid's/gid's now in the export config as they represented a mount security hole. There was a basic flaw in ACTION_FINDUPDATE handling. The meaning for non existing and existing files was reversed, causing the action to basically fail to do the job whenever you needed it. As nobody reported any problems here, I have to assume that it is basically an unused action in real life. I enabled basic read only support as most of this feature stuff has been in there anyway, but there is nothing yet to set that kind of configuration. filesystem.service is now at 43.5. - On reception of a transaction response with a response buffer that is too small (shouldn't happen!), a buffer could have been left lying around. A request for allocation of zero length buffers for AllocTransactionA() will be ignored now. Transaction structures are internally cached now, rather than freed immediately. This should reduce overhead and fragmentation. Incoming requests put together their own transaction rather than using AllocTransactionA(). The reception code for transaction data (request/reply) assumes that transactions are sent in a strictly sequential fashion. Due to the locking rework, this was no longer ensured if some maniac used one entity on multiple contexts in a certain way. This should now be safe again. There was a bug that could break small transactions from a slow to a fast machine. Incoming replies are handled according to their corresponding transaction which is on a wait list. Consider the following scenario. The transaction fits into one packet. The slow machine sends this packet successfully. Before it is able to add the transaction to the wait list now, the server has processed it and replied. This reply is lost on the slow client because the transaction is not yet on the wait list. If the timeout isn't set too short, retransmits will kick in. This seems to be the whole cause of the "5 seconds until reply" problem. Timing the 5 seconds led me to the solution. Locking was incorrect here. Sending the last piece of any transaction and adding it to the wait list on success must be atomic with respect to incoming reply processing. A wrong semaphore was used. I coudl _at_times_ reproduce the 5 second thing, but never the EFS Alert problem. This current nipc problem may actually have been the cause for the EFS invalid lock paranoia alerts for packet type 15. Due to the missed transaction, EFS retransmits may have kicked in here. I just hope nothing else comes up. You may ask why it is so hard to get this right. Here is a short overview about the semaphores juggled for things inside nipc: - Entity: 4 each - RDP Connection: 4 each - Routes: 1 each - Misc stuff: 22 There is a lot of room to err, leaving timing dependent issues aside completely. nipc.library is now at 43.10. - Reestablishing a notification did not use the correct volume. It tried to reference the current one which could have been NULL. EnvoyFileSystem is now at 43.8. - A change for filesystem.service. On [re]connecting, it sent out the mount info before establishing a current volume. Then it sent out the diskchange info for the volume. This caused a timing hole on the client. It got the mount with an info of "no volume inserted". Under the right circumstances, this caused the packet to fail with a "please insert" problem due to quite some concurrent activity in the client. Then the diskchange would be processed and the problem would fix itself automagically after at most ~1 second. Now, the server sets up the volume info before returning the mount transaction. This means that the client will now mount "full" drives whenever possible, rather than "empty" ones for about a second. Incidentally, the solution is in some way a hack. The server "finds" the volume by doing disk change handling internally. So it sends out a diskchange and returns the info about the newly mounted volume afterwards. As the client processes mount info in sync and knows about redundant diskchange messages, there is no problem of transaction order !! here. The debugging output is still in there just in case. filesystem.service is now at 43.6. - In severe low memory conditions the packet write stuff in nipc could dereference NULL pointers, writing into the vector table. nipc.library is now at 43.11. - Major rework for the GUI engine in envoy.library. It now supports gadget "unions" and tagging/query of layout groups to make pages possible. Also non-pixel scaled stretching of gadgets with arbitrary positioning is now supported correctly. Another thing is constant layout tag lists with presets of variable values. This should help stack usage. Option pages via gadget unions require a full window redraw. This is a gadtools problem. Well, unfortunately the layout engine is now about ~8.5KB big. It used to be below 8KB. envoy.library is now at 43.17. !! - Some more rework for the layout engine. You never think of !! everything before you actually start using your work. I did !! not handle some V37<->V39 issues well and was not able to !! fill a cell with a gadget without stretching the cell. !! Network Configuration is tricky and told me lessons on quite !! some issues. You *MUST* use this envoy.library with the stuff !! below! envoy.library is now at 43.18. - Filesystem Exports now uses two option pages, one for the security settings, and one for mount behaviour. The new envoy.library >=43.17 is *required* and a new catalog is not a bad idea. If you want a umask for file or dir creation like thing, you have to come up with a way to integrate it into the GUI. Filesystem Exports is now at 43.7. - Finally, I found the problem with the cycle gadget hit in Filesystem Imports. The layout is again 640x200 compatible now and the login requester uses the presets now if nothing else has been specified. The listview now has a prop font title for GUI consistency with FS Exports. Filesystem Imports is now at 43.7. - Services Configuration started up with a warped service selection. It also makes use of the new GUI tags now for better and consistent looks of, e.g., the listviews and checkmarks. Services Configuration is at 43.5. - Users now also has a nicer GUI. Users is now at 43.3. - Groups now also has a nicer GUI. Groups is now at 43.2. - Network Configuration uses the new GUI stuff now. Not easy at all. It also finally recognizes changes to the realm server address even if you don't hit ENTER. Network Configuration is now at 43.2. - Network Configuration now won't open envoy.library when doing config file based prefs updates. This is needed for a fresh installation. It also asks for an admin user now. Network Configuration is now at 43.4. - Services Configuration now won't open envoy.library when doing config file based prefs updates. This is needed for a fresh installation. It will also no longer open services if a service name is given in the config file and ask for an admin user whith the GUI. Services Configuration is now at 43.7. - The user with uid 0 is now always Admin when set up and can't be removed. On database creation, the "Admin" password is now required for the new "Admin" user. The accounts manager can algorithmically generate non conflicting names for new users now if the prefs tool passes in a NUL name. Groups and users without name can no longer be added or modified. White magic. The manager now needs accounts.library for password !! encryption. I don't like code duplication. You *MUST* use !! this accounts manager now. Accounts Manager is now at 43.2. - accounts.library now uses the new standard library startup code. It is a lot easier to maintain. Fixed numerous autodoc problems. accounts.library is now at 43.1. - Some fairly major rework of the installation script to make it more flexible. The user has to reboot now right after a deinstallation. I thought about algorithmically shutting down Envoy but figured that I could never play it safe with all the installations out there. It is now possible to chose installation directories for devs, libs, l, c, and locale in expert mode. SetPatch will always be installed to SYS:C. It knows that ICard users, typically have unit 1 connected. The problems with missing nipc config files on a fresh installation should be history now with the adapted configuration tools. All drawer icons should now be created when needed. - Users knows about the algorithmic names now and has some magic for a better GUI with uid 0. Users is now at 43.4. - Groups knows about the algorithmic names now. Groups is now at 43.3. !! - Just a reminder. The initial user/pw combination is !! "Admin"/"Admin". The password is case sensitive. - ACTION_CHANGE_MODE was broken for FileHandles in the EFS client. EnvoyFileSystem is now at 43.9. - Hmm. I still have to do something about the printer stuff and the disk is almost full. I probably have to get rid of something on that disk. Hmm. - Network Printing is all new now. It writes a new configuration file which is also read by the new port-handler. Network Printing is now at 43.1. - Reworked my new port-handler for better internal device name management. It also reads the new prefs file now and a reasonably safe shutdown is possible for debugging purposes if you know how. port-handler is now at 43.2. - With a little bit of luck, envoyprint.device should now internally support the magic unit handling which is used to easily redirect PRT:, PAR:, and SER:. Note: I do not care much for backwards compatibility here. envoyprint.device is now at 43.2. - The magic V37 printstart kludge is now a little bit smaller and no longer has a data segment. Envoy V37 PrintStart is now at 43.1. - Added logging support to nipc. Currently, we have some Entity, Transaction, RDP, ICMP, and SANA2 logging to a certain extent but the system is pretty much open ended. I'll add other and more logging messages when needed. To display !! the logging messages, you must run the new magic "NIPCLog" !! debug tool specifying log levels for whatever you want logged. The tool is in the Extras directory of the install disk. It can be started multiple times with different and even overlapping options to get different logs in parallel. Lack of memory results in dropped log messages. Logging is done async and does not affect nipc except for preparing the log message and using PutMsg() on it in case it is needed. Log levels range from 0 to 255 for each subsystem. Don't try anything else. 0 == no logging, 1 == log important errors, <100 == misc stuff, <200 == most internal things logged, 255 == pretty much everything including functions called. You may want to start with 255 to see what kind of stuff is logged. Let me know if you see performance problems even with no logging at all. To avoid such problems I am intentionally not logging individual packets anywhere. Finally, nipc.library is no longer fully relocatable code because it is too big now. Sigh. I also added a missing tagcall proto for the route functions. nipc.library is now at 43.12. - filesystem.service will now copy an internal FIB for Examine_Next only when really needed. This is more an optimization that came when looking for a problem that doesn't seem to be the fault of EFS after all. So it is not really a bug fix. filesystem.service is now at 43.7. - I walked through nipc code to identify and eliminate obscure code and other risks. A math function used in calculating times in PingEntity() would destroy D2. Luckily, this didn't break the caller. The internal checksum function should now be a little more robust and maybe faster for the typical packet. it also handles odd start offsets now on plain 68000 machines. Internally checksumming NIPCBuffs will now take buffer offsets into account. RDP packets with a totally broken header should not be accepted for anything now. When sending IP options with an IP packet (which nipc doesn't!), option padding was broken. It destroyed up to the first three option bytes rather than adding padding at the end. The RDP code now makes a better attempt to get the packet back in shape on retransmits. Previously it made assumptions about what the IP layer did with the data buffer and how it prepended buffer entries for IP headers or ARP management. While the assumptions were correct, I anticipate some changes and made RDP no longer rely on those assumptions "as is". In case of an error on preparing an RDP packet for output, the RDP code will no longer have the data buffer modified. This didn't affect transactions at all but is much cleaner now. RDP retries now count as connection activity. On retries, the new wait is based on the current maximum roundtrip estimate now rather than the current estimate. Retries are started up faster now if needed. All this should stabilize retry behaviour and fix connections where transaction would have timed out already otherwise. RDP logging is much better now. IP packet sending will now try harder to preserve the data areas passed in until the packet is actually sent. See the autodocs. An internal memory management call could have freed a NULL pointer in a low memory situation. I improved ARP handling. Packet timeouts during ARP handling are now connected to the corresponding ARP entries as they should be. With a maximum resolve wait of about 30 seconds with ARP tries every three seconds, ARP should now handle lousy connections much better and should fail a lot less. ARP flooding per IP should no longer be possible. If an ARP resolve is already pending, sent out packets will simply "wait" with the already existing ones rather than causing a new resolve try. On SANA config updates, corresponding ARP entries will finally be killed to avoid stale references. ARP logging implemented and ICMP logging fixed. I added some additional checks for broken incoming IP packets. Thanks to olsen for pushing the log idea. I may well have been to lazy to do anything about this subject myself. It helps a lot, even though the log messages make nipc bigger. nipc.library is now at 43.13. - The option page gadget for Network Configuration now has a label. Network Configuration is now at 43.5. - The option page gadget for Filesystem Exports now has a label. Filesystem Exports is now at 43.8. - nipc.library still had some problems in the checksum function. Added more SANA2, IP, and RDP logging. I added a very evil and ugly hack to throttle packets on retries. A retried packet will cost nipc internally about 20ms time now. The alternative would have been one second intervalls after each retried packet. This 20ms delay is to avoid flooding destinations while still being able to handle broken networking HW. Those with good connections won't be affected at all. I don't like this hack at all, but it seems to be "reasonable" compared to alternatives. nipc.library is now at 43.14. - As it seems, some SANA devices may return more than MTU bytes of data on a CMD_READ. nipc now allocates 64 extra bytes to cope with those broken devices. To support this and better buffer management size checks, I reworked the SANA code a bit and removed strange use of two SANA callbacks in other parts of nipc. For DMA capable SANA devices, nipc now contains an additional sanity check. nipc.library is now at 43.15. - All the prefs editors had WA_AutoAdjust disabled for some obscure reason which kept some of them from opening on small screen sizes. This should no longer be a problem. Also, Network Configuration did not recognize intermediate changes to the integer unit/IP type/ARP type gadgets well. Network Configuration is now at 43.7. Services Configuration is now at 43.8. Filesystem Imports is now at 43.8. Filesystem Exports is now at 43.9. Users is now at 43.5. Groups is now at 43.4. - The password check on startup was incorrect. Network Configuration is now at 43.8. Services Configuration ist now at 43.9, and Filesystem Exports is now at 43.10. - When obtaining the size of the sizing gadgets in the layout code, envoy.library will no longer request a specific size. Now it is left up to sysiclass to find the "correct" size which helps hacks and is a better idea anyway. envoy.library is now at 43.19. - nipc will now truncate incoming oversized packets rather than trying to allocate more than MTU bytes per packet. IP number changes did not update the ARP cache correctly. I changed the prototype for SetDeviceIPAddress() significantly and made NIPCControlA() public. Due to internal numbering conflicts, I also changed the values of previously unused tags in nipc.h significantly. Due to a bug in the ARP code, a NULL pointer could have been dereferenced. A new function AllocNIPCBuffEntryWithMem() is now publically available for more efficient IP protocol support. nipc.library is now at 43.16. - Due to some problems that I encountered, I reworked a2065.device. Error recovery for the lance chip was pretty much hosed. The softint could have problems sending the correct packet. Multicasting and online could have eaten up pending write request forever. If the lance locks up, without apparent reason, the driver will now silently try to restart it. Some cleanup work should result in less Disable() and interrupt activity. AbortIO() was IMHO still flaky for R/W requests. Please test this. - Filesystem Exports didn't fit on a 640x256 screen anymore. It is now at 43.11. - filesystem.service no longer has enabled debug statements. filesystem.service is now at 43.8. - More work on a2065.device. It did not abort a pending event request correctly and reset the configuration status incorrectly. a2065.device is now at 3.11. - For better debugging you can now specify IP addresses as host name for FindEntity() calls. This also affects the host requester of envoy.library which makes use of FindEntity(). The sana code in nipc.library now keeps track of pending requests and aborts them individually on reconfiguration as a CMD_FLUSH doesn't cover pending event requests. In strange situations, this could have hung nipc.library. nipc.library is now at 43.17. - Minor enhancement to envoy.library. A private IDCMP management function can now be called as single shot callback for better support of async window management. Also, flags have been added internally to support shared IDCMPs. This was needed for the printer stuff. envoy.library is now at 43.21. - My new port-handler 43.4 now supports quite some stuff: 1. PRT:TRUERAW uses PRD_RAWWRITE instead of sending an ESC. 2. full duplex io should be possible. 3. Timeout handling for PAR: and SER: 4. Special PAR:/SER: redirection capabilities for network printing support for dumb applications. 5. Can display the rate with the GUI/NOGUI options 6. SER:FAST can be specified to get RADBOOGIE 7. TIMEOUT= can be specified for selective abort 8. Should autoabort any timeout requester if the request finishes afterall. - I updated Network Printing to support the new port-handler prefs as needed. Note that printing redirection with this tool will not work as expected until the new print server is in place. Timeouts should work, though. They are always valid, not just when something is redirected. A timeout value of 0 means "wait forever"! Network Printing is now at 43.2. - nipc.library way a little bit restrictive about subnet masks. I changed a single line to make it more flexible. nipc.library is now at 43.18. - Filesystem Exports did not have the OldUID/GID texts localized. It is now at 43.12. - The all new Printer Exports is finally working as it is supposed to be. Note the new name with an "s" at the end. Note that it will write a new prefs file with a new name. It will not pick up old prefs. Default Exports "SER", "PAR", and "PRT" are prepared but not activated if they are not yet set up. This is to support the magic standard redirection of a !! client's SER:/PAR:/PRT: dos devices. It will not do anything !! with the old printer stuff. Printer Exports is now at 43.3. - envoy.library had a little quirk in the layout engine. When spreading out gadgets it spread out gadget sizes even when it shouldn't have. I need a special requester for the new printing system. Rather than duplicating yet another piece of requester code, I unified the requester code used and made it accessible in majik, clean, and private ways to external parts of Envoy. Obviously this means that all requesters generated by envoy.library need to be retested in detail. Let me know if behaviour, memory usage, stack usage, or keystrokes/tabbing changed in adverse ways. BTW, the password entry gadgets are once again restricted in cursor movements. Let me know if this is a problem. envoy.library is now at 43.23. - Many locale changes. Obviously this is somewhat preliminary. - *sigh* My last "improvement" to nipc.library killed default settings for subnetting which in effect tends to kill any kind of communication. This should be fixed now while still keeping the net masks flexible. nipc.library is now at 43.19. - *sigh* All the prefs editors used an IntuiMessage after it had been replied to. This bug has been in there forever and is also affecting the AmigaOS prefs editors, even though it may not be generally noticable. Groups is now at 43.5. Users is now at 43.6. Network Printing is now at 43.3. Printer Exports is now at 43.4. Filesystem Imports is now at 43.9. Filesystem Exports is now at 43.13. Services Configuration is now at 43.10. Network Configuration has been reworked as listed below. - To support a few necessary features for general interfacing, I decided to rework the Devices panel in Network Configurations. Any used SANA2 device parameter set will now have a unique interface name that is of use to some internal nipc functionality that is not of concern to the casual user. The program takes great pains to always keep the names reasonable and unique. Also, automagic gadget activation should help entering data a bit now. Incidentally, it works more like all the other Envoy prefs tools now. Hmm. In fact, Filesystem Exports really should use the export names, too. Hmm. Network Configuration is now at 43.9. - Another revision for the envoy.library GUI engine. I added a new function to put an abstraction layer into GUI creation. I also added a magic identifier for a new selection gadget that doesn't look all that new to the user currently. This is needed (now) by the reworked Network Configuration and will be needed by more stuff in the future as prefs grow. envoy.library is now at 43.24. - Another locale update. Won't be the last. - NIPCLog didn't pass all the options on to nipc.library. I also changed the version to V43. NIPCLog is now at 43.1. - nipc.library will now add the internal routes for the sana devices with the correct subnet masks. ICMP redirects, timestamps and address mask requests should now be handled correctly. Especially redirect handling was pretty bogus. Added UDP logging. Routes for specific hosts are now handled correctly even with net routes being available for the same net. There was a bug where routes with less significant netmasks that were added later would obscure more significant routes. A simple two slot cache should make route and ARP lookup faster. With two 060 machines and halfway decent Ethernet boards, it should be possible to get DiskSpeed to RAM: with >700KB/s. My test setup with an 040/40 and 060/50 maxed out at about 695000Bps. Added some Resolver logging. nipc.library is now at 43.23. - Issue: nipc.library currently has a few non localized requesters for SANA problems. Should these be localized, too?! There may be a need for more messages in the future, e.g., to notify about duplicate IP addresses. Let me know what you think. - Due to a very strange bug report about unreliable RDP (hah!) I checked the RDP code and found a potential hole, even though I could not reproduce the actual reported bug. Plugging the hole the right way raised RDP efficiency by well over 10%. With the setup described above, I get peak rates of >775kBps now. This is through the RAM handler, EFS Server, a2065.device, ariadne.device, EFS client, the transaction mechanism on both side, RDP of course, and the IP layer. Pretty efficient, don't you think? Well, anyway, the bug was an nipc Alert about a lost RDP packet that simply can't happen. I added a few RDP diagnostics to catch stuff like this. If you want to find bugs here, keep nipclog with LOGRDP=10 in the background nipc.library is at 43.24. - There was a rather serious bug in nipc.library. Whenever you changed the prefs, nipc reconfigured itself. Due to the changes with >=43.19, it did not set up the ARP entries for SANA2 devices correctly again in this case. Net result: All connections lost. nipc.library is now at 43.25. - Until I find the cause for the alert in nipc that tells me about internally broken transactions, I added some paranoia code so that this data can't cause any harm in upper levels. Basically, you won't get an Alert 07000004 anymore. You can still track that problem with NIPCLog, using an entity log level of 1 though without flooding yourself in useless messages. log levels of one always tell you about serious problems only. This should help during standard use while at the same time allow us to locate the source of the problem. nipc.library is now at 43.26. - Printer Exports has slightly renamed default names. It no longer allows a delete of the default entries but the user can still rename them as she wishes. I am not sure that I am completely happy with this, yet. Printer Export is now at 43.5. - The first cut of the new Printer Imports tool is finally done. It looks a lot like Filesystem Imports. You can import printers for Default Printer Output, PRT:, PAR: and SER:. It should be possible to import multiple printers from different machines for each mode respectively. Each new import for a certain mode should override any old one correctly. Printer Imports is now at 43.2. - envoyprint.device should now handle the new printer stuff, too. It is now at 43.3. - The new Envoy Print Spooler (EPS) shows first signs of life for the first time ever. It will read and evaluate the prefs and tell the new Printer Imports about them. It also accepts files and seems to print them well. Known limitations and issues at this point of time: - Doesn't pick up old spool files after a reboot yet. - The few diagnostic requesters don't have locale support yet. - No loop protection yet. The spooler will happily print to envoyprint.device. Hmm. Feature or bug? - No command(s) for status/queue management yet. Issue: What should be possible/visible and for whom? - How the heck should errors be handled once the spool file is ready to print? Examples: Failure to write data to device or lack of memory for management data. I can't tell the client. Hmm. Any ideas? - Logins for printer exports with security don't yet seem to work. Probably a messed up user/pw check. Magical debugging feature. A CTRL-F will shut down the print spooler task. printspool.service is now at 43.1. - NOTE: ALL THE PRINTER PREFS FORMATS AND FILE NAMES HAVE CHANGED! - A few notes on how to sue the printer stuff: 1. You always have some default exports for the server's parallel, serial and printer device. You also have a default export to get the current output device for any printer data generated by printer.device on the server, whichever that may be. 2. Default exports can be freely renamed and turned on/off, but they intentionally can't be deleted. 3. EPS exports can have security, much like EFS exports. 4. The imports tool only handles prefs. It does not activate or deactivate any redirection. That is left for "Network Printing". 5. Printer Imports is based on four steps - Select the server machine - Select which printer to manipulate - Select the mode to use for this printer - Connect. There are some implications and magical things here. First, you have to Connect in the "No Connect" mode to disconnect a printer. Any printer connected with a certain mode will override any previous printer for that mode. You can only have one imported at a time for a single data path. If you don't have any default printer output set up yet, the mode will automagically suggest this to you. This is for poor Joe User who doesn't care about DOS redirects. 6. No reboots needed for any configuration changes. - printspool.service will now report printers using security correctly. It is now at 43.2. - Printer Imports would create duplicate prefs entries when changing the mode for an import. Net result was strange import mapping. It is now at 43.3. - Open issue: How do I handle loop deadlocks? Imagine this: User exports printer.device/0 as "PRT:". User imports "PRT:" as Default printer output. User activates default printer redirection. User does "echo test >prt:". PRT: uses printer.device 0 ==> data goes to envoyprint.device ==> spooler ==> printer.device 0. Boing. Any ideas? - I think I found a reasonable solution now that still keeps local printing over the spooler intact. If the spooler would be printing to printer.device/0 using envoyprint.device, it refuses to accept the job. If it would print to the default printer.device output currently being envoyprint.device, it will print to parallel/serial.device appropriately instead, to break out of a print loop for a local spool import. No locale support yet and some notification for failing writes to the final output device is still missing. printspool.service is now at 43.3. - I forgot a little feature in the layout functions of envoy.library which is good both for the code using the layout functions, symmetry in internal functionality, and my health. What it was? It's indexed extra info gadget tag support via one new private tag. I used this in Printer Imports. envoy.library is now at 43.25. - Printer Imports uses the new tag now, so envoy.library 43.25 is required! Printer Imports is now at 43.4. - filesystem.service accepted a zero lock for ACTION_CHANGE_MODE which really didn't make too much sense. Also, via magical ways it was possible to modify protected .backdrop or Disk.info files on the server. If Disk.info is protected, it will now be read only, not made invisible. This finally fixes the problems with the original icon of an import not being used. Hard links to a protected Disk.info will no longer be possible either. Let me know if you find any way to access/modify either .backdrop or Disk.info if the export isn't configured to allow it. Be creative :^). filesystem.service is now at 43.9. - The EFS server now supports a new internal prefs flag for removeable media which is basically identical to an empty export name. I need this to rework the Filesystem Exports tool. filesystem.service is now at 43.10. - Filesystem Exports now behaves like the new nipc prefs or the printer prefs. It will display the exports in the list view and the path in the gadget to the right. As an empty export name is no longer possible to signify removeable media, you have a checkbox for this now. Previously empty export names get defaults and export names are now made unique to make imports non ambiguous. Net result is that even RMS exports can always have a decent name now without revealing what device on the server is used. NB: If this is used with an old filesystem.service, RMS support is deactivated. I don't see this as a significant problem as mixing installations on one machine is not a good idea. Filesystem Exports is now at 43.14. !! - So much has changed that most likely pretty much everything !! is incompatible to Envoy 2.0 now. Just thought I mention it. !! An Envoy 2 and Envoy 3 setup won't be able to communicate well !! if at all. - Implemented a missing command in envoyprint.device. envoyprint.device is now at 43.4. - ARP code could cause enforcer hits in low memory situations. Added some paranoia checks and log messages to catch bad ARP entries. ARP cache will now be flushed on any config change to make sure that network reconfigurations are picked up ASAP. Querying sana devices via the ioctl like mechanism had a flaw. The IP code will now (like the ARP code) report a level one log message if it detects duplicate IP addresses or other very bad things. nipc.library is now at 43.27. - Sigh. Took me quite a while to locate a problem in envoy.library. It could happen that it called GT_SetGadgetAttrs() on the context of input.device. This in effect causes intuition to misbehave in a certain way which causes gadtools to mess up the gadget list in the end. Net result is that you get single gadgets added twice to a list just because you tried to disable or enable them. Ouch. Also, cursor positioning in the magic password gadgets was incorrect after a resize. All this should be fixed now. envoy.library is now at 43.27. - Even as admin, you had to know the old passwords to change a user's password. This was stupid. An admin can now change any pw. Users is now at 43.7. - I needed a new error code. So nipc.library got rebuilt because errors.h is anchored there for hysterical reasons. nipc.library is now at 43.28. !! - While writing the tutorial for the Groups preference editor, !! it turned out that Groups was really non functional. Tracing !! this problem turned up *MAJOR* flaws in *ALL* the accounts !! management. OUCH. Major rework for about everything here! - Accounts Server completely reworked. It is totally incompatible now to the old accounts.library. This is intentional and does not affect the database files. Lots of problems fixed. Lots of them. It is now at 43.4. - accounts.library reworked. Lots of internal magic added to support prefs editors in a decent way. Prefs editors no longer need to make assumptions about internal workings of the server. !! Note that accounts.library is much more restrictive now with !! respect to passed in data. Check the autodocs! Incompatibilities !! are intentional and accepted. accounts.library is now at 43.2. - envoy.library reworked. A feature in the password requester had to be added due to the fact that passwords are no longer passed back from the Accounts Server! envoy.library is now at 43.28. - Users and Groups totally rewritten inside. They should also behave a lot more similarly now and use decent error requesters. Users is now at 43.9. Groups is now at 43.5. - locale completely updated for the new accounts stuff. - Accounts Manager would allow a user to be added to a group twice. It is now at 43.5. - Added basic context sensitive help support due to a very reasonable request. This is reasonably simple currently to keep the amount of work reasonable and really works only with >=V39. Let me know if you think this is a problem. Services Configuration is now at 43.11. Network Configuration is now at 43.10. Filesystem Imports also tries to create icons now for paths that it creates and is now at 43.10. Filesystem Exports is now at 43.15. Users is now at 43.10. Groups is now at 43.8. Network Printing is now at 43.5. Printer Imports is now at 43.5. Printer Exports is now at 43.6. - printer.device not only is a pain, it really sucks. As it turns out, it doesn't really check io_Error on writes to the underlying output device. The only error indication it understands is a device not returning a request, i.e., the request timing out. envoyprint.device now contains a kludge _not_ to return erroneous writes. The requests are kept until the caller aborts them. *sigh* This most likely was the #1 cause for network printing problems. envoyprint.device is now at 43.5 - Shutting down the print spooler could lose memory. I also finished the basic management interface. printspool.service is now at 43.4. - Added a little Shell tool SpoolMgr to handle the print queue. Would be nice to make a commodity, but right now I don'thave the time. It would only be a gimmick anyway. spoolmgr is at 43.1. - Printer Exports didn't handle the magic default printers well. It is now at 43.7. - Network Configuration could deref a NULL pointer in batch mode. It is now at 43.11. - Hopefully this is a release freeze now. Bumped EnvoyFileSystem to 43.10. filesystem.service is now at 43.11. accounts.library is now at 43.3. envoy.library is now at 43.29. services.library is now at 43.2. nipc.library is now at 43.29. Services Configuration is now at 43.12. Filesystem Exports is now at 43.16. printspool.service is now at 43.6. Filesystem Imports is now at 43.11. Accounts Manager is now at 43.6. Users is now at 43.11. Services Manager is now at 43.2. - In parallel to the context help stuff, I obviously wrote manual text and context help text. LOTS of text. I just hope it makes any sense. Please send me some feedback on the text. - Cleaned up and checked the full build engine. Did the first total cleanup of the RCS tree and build from scratch in a while! Today is 13.sep.98. - The print spooler did not work well for slow output devices. It had a default timeout of 30s/8KB of data. I changed this to be configurable and changed it to 15s/1KB as default value. A value of 0 means that no timeout check is done, which may !! cause a wait that lasts forever! Please load and save your !! export config once to have it saved in the new format! Printer Exports is now at 43.8. - Aside from handling the new configurable timeout now, print error requesters will no longer block network handling of the spooler. If one printer fails to accept data, others should continue to accept data from the network. Also if jobs for the printer are failing to accept data, the spooler should still accept more jobs. The print spooler will only refuse to handle transactions if it can't write the job files. In that case the user has to fix the problem first and ack the EasyRequest. You can also hold and release jobs currently in the print queue now. Holding the currently printing job means stopping the queue. Releasing it means restarting the queue. The printspool.service is now at 43.8. - SpoolMgr now reports the job status, is a little easier to use, defaults to "LISTJOBS" unless other options are given, and can hold/release jobs. SpoolMgr is now at 43.4. - Updated the manual and the online help to reflect the new variable timeout option. - German and english docs basically done. - Final testing - Layout tag tweak to make Network Configuration fit on 640x200 V37 screen. It is now at 43.12. - The install script should be a little smarter about subdirs now. - Envoy 3 release. Finally. *sigh* Heinz Wrobel /*------------------------------------------------------------------------*/