From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9ead16deb8bf1dd6d0bc7904bb2f88e8@krabbe.dyndns.org> To: <9fans@9fans.net> Date: Thu, 18 Sep 2014 10:20:54 +0200 From: Ingo Krabbe In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Annyoing modified by boyd Topicbox-Message-UUID: 16dd9c9c-ead9-11e9-9d60-3106f5b1d025 > "FILE modified by boyd since last read" strikes me as more useful than most > error messages I see these days. My only question is what particular weapon > Boyd would have used to "modify" the file. Hey Winston, I agree that the message itself would be extremely useful if it would be reported correctly. But acutally when its just me who modifies a remote file with acme in a editing session, I get these modified by boyd warnings and I will get the same warning if someone else had modified the file, in the end this really useful message gets useless, as most times it is wrong and gets auto-ignored by the chair-to-keyboard-interface. FYI: boyd is the unknown modifiying user of any file on cifs, who is a friend of bill and trog. I always think of boyd to be the younger brother of void. Regards Ingo Krabbe > On 17 September 2014 23:18, Ingo Krabbe wrote: > >> Hey, >> >> using legacy bell-labs plan9 (I don't know the others), I often, that >> converges to always, get "FILE modified by boyd since last read" when >> editing a file on a cifs share with acme. >> >> The cifs main.c defines "boyd" as the "modifying user" (muid) in I2D and >> V2D, which are from fs.stat. >> >> From /sys/src/cmd/acme/exec.c:/putfile/+14 >> >> if(d!=nil && runeeq(namer, nname, f->name, f->nname)){ >> /* f->mtime+1 because when talking over NFS it's often off >> by a second */ >> if(f->dev!=d->dev || f->qidpath!=d->qid.path || >> f->mtime+1mtime){ >> f->dev = d->dev; >> f->qidpath = d->qid.path; >> f->mtime = d->mtime; >> if(f->unread) >> warning(nil, "%s not written; file already >> exists\n", name); >> else >> warning(nil, "%s modified%s%s since last >> read\n", name, d->muid[0]?" by ":"", d->muid); >> goto Rescue1; >> } >> } >> >> Hmm, possibly this is another time quirk, like that one from NFS. Does >> anyone know a good solution to that problem? >> >> Regards >> ikrabbe >> >> >> >>