[00:00:48] --- steven.jenkins has left [00:10:30] --- steven.jenkins has become available [00:14:32] --- dev-zero@jabber.org has become available [00:23:00] --- kaj has become available [00:29:03] --- haba has left [00:56:27] --- Russ has left: Disconnected [01:02:23] --- haba has become available [02:02:08] --- abo has left [02:03:01] --- abo has become available [02:46:19] --- jaltman has left: Replaced by new connection [02:46:20] --- jaltman has become available [05:00:41] --- Jeffrey Altman has become available [05:18:31] --- jaltman has left: Disconnected [05:18:38] --- jaltman has become available [06:02:03] --- meffie has become available [06:26:03] --- abo has left [06:26:20] --- abo has become available [06:52:37] --- deason has become available [07:18:01] --- reuteras has left [09:12:30] --- shadow@gmail.com/owl7F31A9A2 has left [09:14:34] --- dwbotsch has left [09:15:31] --- dwbotsch has become available [09:52:35] --- haba has left [09:58:07] --- kaj has left [10:33:16] --- shadow@gmail.com/owl5BDB22A1 has become available [10:36:33] --- dwbotsch has left [10:37:13] --- dwbotsch has become available [10:42:03] --- Russ has become available [10:49:13] --- Kevin Sumner has become available [10:51:16] Any thoughts on whether it's a bad idea to include a struct mtx inline in struct afs_event (instead of just having a pointer to an external mtx object)? [10:55:48] given that patch will make it like macos and i can then merge, i'd rather get a thumbs up/down on that and then if you want more changes we can try on both fbsd and macos [10:57:50] This is for the "actually allocate storage for the struct mtx" patch that I haven't written yet. [10:58:54] macos has lck_mtx_alloc_init which appears to do the allocation already. [10:59:02] you want to do what? oh, that [10:59:14] yeah, ok [10:59:51] (I assume there is also a lck_mtx_init variant that does not allocate) [11:00:40] But the quick hack I've been running with seems to need to zero the space for the struct mtx, as otherwise I got some crashes where it claimed the mutex was already initialized. [11:15:09] ok. time to see if afs mac is indeed broke or not [11:18:08] > ok. time to see if afs mac is indeed broke or not and? [11:18:19] gotta install your package from the other day, first [11:18:43] (I did a cp from the commandline into a dropbox folder and the computer crashed) [11:18:46] that takes a few seconds :) [11:18:58] old version, or new? [11:19:22] or was the issue that crashing prompted you to try this? [11:19:37] the 1.5.71, I think [11:19:52] ok, then i know that is fixed [11:20:06] altho, at least w. that version, I can't drag the file from afs to my desktop (not in afs) [11:20:26] if at first you don't succeed [11:20:27] try again [11:20:44] basically, finder issues for anything older than what i pushed on port-darwin are uninteresting now, because the code is way different [11:20:58] hence why I'm gonna try it [11:22:23] --- abo has left [11:22:40] --- abo has become available [11:26:04] --- meffie has left [11:27:33] finder took about 50 seconds to bring up my root.cell volume (which the host itself has rl acl on) [11:28:14] some of the mountpoints in there, it only has 'l' acl on, tho [11:28:27] better? worse? [11:28:35] that's better than it used to be [11:29:08] the next levels of folders (in which it grp_hosts has rl) is coming right up [11:29:11] does tail /var/log/kernel.log show any server timeouts? [11:29:12] as I drill down [11:29:27] (or, run the growl agent and it will tell you in real time) [11:30:07] afs: Lost contact with volume location server 66.207.142.196 in cell bazquux.org [11:30:35] that's 50 seconds. [11:31:02] tho. maybe no? do you have mount points for it in root.cell? [11:31:06] or is that your cell? [11:31:23] not my cell [11:31:25] but it is there [11:31:34] must be in the cellservdb [11:31:42] (tho, the dynamic root.afs came right up) [11:31:57] correction.. it is there in root.afs, not root.cell [11:32:00] there's a mount point for it in root.cell? or in root.afs? [11:32:02] ok [11:32:33] where is this growl agent of which you speak? [11:32:41] --- abo has left [11:32:54] --- abo has become available [11:33:26] sudo fs mariner localhost /Library/OpenAFS/Tools/tools/growlagent-openafs & [11:33:34] --- deason has left [11:34:09] --- deason has become available [11:34:40] fs mariner? :) [11:35:34] and there is no growlagent-openafs in that directory [11:35:46] uh. you're leopard? [11:35:50] snow leopard [11:36:01] it's there in the install i did. hm. [11:38:02] AFS version: OpenAFS 1.5.72 built 2010-03-03 [11:38:30] oh. that's old. hm. [11:38:33] which did you install? [11:38:37] I copied that two days ago [11:38:52] which dmg? [11:39:22] OpenAFS-1.5.72-Snowleopard+bulkstat+umove.dmg [11:39:29] grab a new one [11:39:37] what's the path, again? [11:39:53] /afs/andrew.cmu.edu/usr/shadow/... [11:40:51] bulkstat+umove again? [11:42:10] AFS version: OpenAFS 1.5.72 built 2010-03-09 [11:44:17] could not find local GrowlApplicationBridgePathway, falling back to NSDNC ? [11:45:36] but seems to be working [11:45:46] same file, yes [11:46:02] do you not have growl installed already? [11:46:19] lots of error 49733388 replies from the fileserver as finder attempts to fetch-status in a directory it only has the l acl on [11:46:30] yeah. that happens. sorry. [11:46:48] I did a full install of 10.6 and I installed XCode [11:47:04] and finder is taking a while to come up with said folder [11:47:27] first level came up, but tcpdump was still showing the fetch-status and error replies [11:47:51] went ahead and clicked down one level, been over 50 secs, now... and it's still doing the fetch-status and error 49733388 replies [11:48:07] the fileserver will throttle you [11:48:42] well, what's been interesting is that if I give myself tokens (which gets me rlidwka on the direcftory), it will usually then pop right up [11:48:51] yes. [11:48:57] because you stop getting lots of errors [11:49:30] ls -l in the directory without tokens would have the same issue [11:49:33] so, the fakestat doesn't help with this scenario (folder is a dropbox) [11:49:56] no... ls -l returns immediately [11:50:05] fakestat, or fakestat-all? [11:50:12] yes [11:50:52] fstrace, if you can. i'd like to know if it's getting errors on ._ files [11:50:55] --- abo has left [11:51:03] ls -l doesn't seem to do fetch-status... seems to do inline-bulk-status [11:51:18] --- deason has left [11:51:19] so should finder, at least once. [11:51:22] --- abo has become available [11:51:31] --- deason has become available [11:52:16] fstrace setset -set cm -active [11:52:24] then just fstrace dump every so often? [11:53:51] sure, that'd be fine [11:55:53] http://pastebin.com/dPcUyeVA [11:57:31] this appears to be looking stuff that's not even in the folder I'm waiting on finder to return in [11:57:53] it does stuff "in the background", so you may have noise [11:57:59] so it seems [11:58:19] like, it tries to also stat() other things [11:58:23] --- haba has become available [11:59:03] so, anything in particular I am looking for in the trace output? [11:59:49] so, for the purposes of a dropbox (incoming folder) in afs, w.r.t. finder, it would seem to be broke [12:00:01] explain? [12:00:15] let's say I wanted to put drop a file in this dropbox folder [12:00:22] so, I attempt to open said folder in the finder [12:00:27] 10 minutes later, finder is still spinning [12:00:56] finder presumably wants information it can never have. [12:01:03] so, I can't put the file in there [12:01:23] dragging into it (rather than opening) doesn't work? [12:02:00] finder won't let me drag it in there (one of those No symbols appears over the file as I attempt to drag it over that folder) [12:02:23] ok. so the issue is finder doesn't believe you have access. [12:02:30] that's one issue, yes [12:02:33] --- deason has left [12:02:41] well, i don't care that you can't see what you can't see [12:02:54] --- abo has left [12:02:58] --- Kevin Sumner has left [12:03:17] i assume if i can figure out how to tell finder "dropbox" it will stop trying to look [12:03:20] --- abo has become available [12:03:31] --- deason has become available [12:03:33] maybe [12:04:21] looks like afs is set to do fakestat-all [12:08:27] is the fetchstatus for the same fid? [12:09:23] tries one 3 times, get a 47933388, then moves onto a different one [12:09:43] are any the fid of the dropbox? [12:09:49] (fs getfid) [12:11:59] at the moment, don't appear to be (they are for somewhere in my volume, tho) [12:12:12] --- dev-zero@jabber.org has left [12:12:23] most folders for which it will only have a 'l' acl on [13:57:04] --- mdionne has become available [14:49:29] POSIX requires declaring volatile any variables local to the function in which setjmp was called that might change between setjmp and longjmp if you want their contents to not be garbage. [14:49:38] After longjmp, that is. [14:52:58] Yuck. And having just read the rest of that code, double yuck. [14:54:10] Yeah, usually the best way to solve any problem involving setjmp is to find a way to stop using it. [14:58:00] agreed [14:59:24] yeah, simon; the answer to "are there better tools for the job" is... don't design things the way they are in vos/vsprocs/etc [15:00:39] the only way I can think to do this correctly without largely changing RX (I think) is to have another thread triggered by the handler, which is dedicated to the recovery stuff... but can you stop an RX call in progress at all? [15:01:30] "triggered by the handler" as in, you have another thread running that gets signalled by a write to a pipe or something from the handler [15:02:53] --- abo has left [15:03:33] --- abo has become available [15:03:33] --- abo has left [15:06:37] is the goal to have a call started in thread A canceled by thread B? [15:08:53] The goal, as far as I can see it, is to be able to tidy up after a SIGINT. [15:09:39] obviously we can't prevent the data that was already sent from being received but we can mark the call as dead [15:11:21] jaltman: basically yes; well, cancelling a call from thread A would be good, too, but we don't get control back until it finishes [15:12:01] hm, but with regular calls we don't even have the call ptr [15:15:19] killing all of the calls of a particular conn would be sufficient for this particular use, though, I think [15:39:35] --- deason has left [16:21:56] --- jaltman has left: Disconnected [16:49:53] --- kula has left [17:08:38] --- kula has become available [17:13:33] --- summatusmentis has left [17:14:48] --- phalenor has left [17:24:50] --- phalenor has become available [17:26:54] --- steven.jenkins has left [17:27:15] --- steven.jenkins has become available [17:34:26] --- summatusmentis has become available [18:08:44] Can I add gerrit as a remote and have it do the right thing? [18:10:25] (At the moment what I am really trying to do is download a patch from a text console.) [18:34:07] --- jaltman has become available [18:36:20] --- steven.jenkins has left [18:36:28] --- steven.jenkins has become available [18:38:10] --- Kevin Sumner has become available [18:42:58] --- phalenor has left [18:52:55] --- phalenor has become available [19:26:07] --- dwbotsch has left [19:26:30] --- dwbotsch has become available [19:28:22] --- dwbotsch has left [19:29:46] --- dwbotsch has become available [19:40:59] --- mdionne has left [20:20:38] --- Born Fool has become available [20:29:19] --- deason has become available [20:30:31] for pulling, as far as I know gerrit is exactly the same as a normal git repo [22:13:09] --- reuteras has become available [22:19:12] --- deason has left [22:20:16] --- Born Fool has left [23:09:49] --- kula has left [23:10:24] --- Russ has left: Disconnected