[00:01:17] --- reuteras has become available [00:55:13] --- dlc has left [02:34:25] --- dev-zero@jabber.org has become available [02:34:33] --- dev-zero@jabber.org has left: offline [04:20:44] --- SecureEndpoints has left [04:38:33] --- SecureEndpoints has become available [05:21:31] --- SecureEndpoints has left: Replaced by new connection [05:37:30] --- SecureEndpoints has become available [06:36:10] Looks like we inherited a bit of a mess from IBM. [06:37:39] volumeId is defined as "afs_uint32" and in several of the protocol messages volume Ids are afs_uint32 but in others they are "afs_int32". Even within the same structs it is sometimes the case that volId is afs_uint32 whereas cloneId is "afs_int32" [06:38:17] And, presumably, changing it on the wire requires new RPCs? [06:38:38] that is a discussion for afs3-stds [06:38:53] if we are strict 'yes'. [06:39:24] we may have to restrict the max volId value to 2^31-1 [06:39:36] I guess the question is whether it will make a difference to legacy clients if we change it. I don't know enough about the difference between uint32 and int32 in the rx encodings is. [06:40:48] the [nu]vldbentry structs are already using afs_uint32 so it should not affect the clients. Except that the clients might be using afs_int32 for the volumeId. [06:41:43] Unless it's legal to have a negative volumeId, do we actually care? The conversion isn't lossy. [06:42:14] I don't think the clients care [06:42:42] cm clients that is [06:44:34] Presumably the only place it's an issue is where volumeIDs are being generated or compared. Everything else will be getting a volumeID from somewhere, and sending it to somewhere else, and then it doesn't matter what the type is, as long as the bits are preserved. [06:47:28] I suspect the failure case here is "if (cloneId == volumeId)" where cloneId is signed and volumeId is not and the comparison is being performed on a system with 64-bit ints. [06:47:53] rx/xdr_int32.c looks like it treats them the same, but this is at quick glance and with very little caffeine in my system [06:47:58] Sounds likely. [06:49:12] if i'm even looking in the right place.... [06:49:38] I've just taken a quick pass through the code and produced a patch that would make everything use afs_uint32 or VolumeId (when possible) [06:50:01] At the very least the patch will point out where the issues are [06:50:34] simon looks like the next set of warnings to get rid of are signed vs unsigned [06:50:55] can you take care of that by tomorrow? :-) [06:52:53] sed -e 's/afs_int32/afs_uinit32/g' [06:53:22] :)) [07:43:03] --- Rrrrred has become available [08:00:46] With regards to the Quorum Completion paper, I got hold of a copy, but through one of the electronic journal subscriptions we have here. Does anyone have an unencumbered copy? [08:05:11] yes... [08:05:20] need to dig it up, though. [08:10:03] sxw - this is the link I had; doesn't seem to work atm, though: http://www.mirrors.wiretapped.net/security/cryptography/filesystems/arla/prog-afs/shadow/doc/ubik.ps [08:10:17] Unless there's more magic in 1.5 than 1.4, I don't see how a system with 64 bit ints would work as an afs client. [08:10:19] iirc, the arla site has copy, but I couldn't find it just now. [08:12:02] http://ftp.eu.openbsd.org/pub/arla/OldFiles/prog-afs/shadow/doc/ [08:12:37] Also works without OldFiles, but that's what google found for me [08:26:42] cg2v - tx. [08:31:29] --- mmeffie has become available [08:31:49] ooh cool [08:38:41] i don't know if there is an unencumbered copy, alas [08:38:41] Does anyone remember where the Mac OS X panic log decoder is? [08:39:26] src/packaging/MacOS [08:39:42] the paper in my directory isn't the whole that that's in the IEEE pub, i thought [08:44:55] sorry, i've not really been looking at the Rename thing. seems pretty easy: just log the old and new fid in SAFSS_Rename, either it changes or not. [09:07:19] --- reuteras has left [09:51:34] Don't know if you say cg2v's stuff - there's another rename issue. We should sillyrename where the target exists, and is open. [09:58:53] I've got a user who's seeing a problem where copying a large file from home consistently fails with a RX Abort from the fileserver. I have a packet trace, is there anything I should be specifically looking for? [10:09:28] FileLog says? [10:10:02] --- Russ has become available [10:10:04] Nothing of any interest that I can see. Upload ends with an RX Abort with an Abort code of 105. [10:11:01] increase filelog verbosity & take quick peek at rxstats to make sure nothing obvious there? [10:12:29] I'll give that a go. [10:20:44] --- mmeffie has left [10:41:57] simon, you want... STABLE14-rx-idledead-only-ignore-keepalives-20081222 [10:42:15] Server or client? [10:42:24] server [10:42:30] Okay. Ta. [10:45:15] he mentioned the lack of sillyrename on zephyr a week or so ago, i just haven't had a chance to figure out how to do it [10:45:53] I can see how to do it, I think, but the locking sucks. [11:01:00] Well, if you can find the abort packet, the error code might tell us something [11:01:12] oops. Didn't scroll down [11:38:36] --- dev-zero@jabber.org has become available [11:39:30] --- dev-zero@jabber.org has left: offline [16:26:36] --- Simon Wilkinson has left [16:30:42] --- Simon Wilkinson has become available [17:49:20] --- mdionne has become available [18:13:11] --- Russ has left: Disconnected [18:31:52] --- Russ has become available [19:07:38] --- mdionne has left [19:33:46] shadow - presumably the dynamic vcache patches are a pain to apply? [20:14:03] > shadow - presumably the dynamic vcache patches are a pain to apply? [20:14:07] they were. i dealt. [20:14:38] the other thing was it undid things like the doxygen commenting (i fixed that) and created non-static internal functions (i fixed that) [20:14:44] i recognize the latter was my fault [20:16:01] for 1.4.x it was fine, of course [20:27:59] yeah, time from when the first version of that patch was written to when it was finally submitted was too long.. :( [20:28:06] at least it's done now. tx. [21:07:09] --- Simon Wilkinson has left [22:35:31] --- Russ has left: Disconnected