Re: [9fans] Annyoing modified by boyd
I'm not sure how kindly Boyd would have taken to being referred to as "the younger brother of void". I suspect not well, although I'm not sure which particular weapon he would have reached for in this instance: http://www.petting-zoo.net/~deadbeef/archive/1023.html On 18 September 2014 21:09, Steve Simon wrote: > FYI > > bill and trog are lifted from the names the dossrv file system generates, > I assume bill is Bill Gates and trog is from the film [1], dos and by > association cifs use old file structures which live under a rock. > > I needed a last modifier name and chose boyd as a little tribute to him, > a man who gave me many a guilty chuckle over the years. He lives on > in plan9 in some dusty corners (mainly in fortunes). > > [1] http://en.wikipedia.org/wiki/Trog > > -Steve > >
[9fans] ipv6 /lib/ndb/local example?
Hi, My new ISP supports ipv6, so I thought I would have a go. I know next to nothing about ipv6 and it would be great to have a /lib/ndb/local to study. anyone got one they would be willing to share. Thanks, -Steve
Re: [9fans] Annyoing modified by boyd
FYI bill and trog are lifted from the names the dossrv file system generates, I assume bill is Bill Gates and trog is from the film [1], dos and by association cifs use old file structures which live under a rock. I needed a last modifier name and chose boyd as a little tribute to him, a man who gave me many a guilty chuckle over the years. He lives on in plan9 in some dusty corners (mainly in fortunes). [1] http://en.wikipedia.org/wiki/Trog -Steve
Re: [9fans] Annyoing modified by boyd
> "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
>>
>>
>>
>>
Re: [9fans] Annyoing modified by boyd
Hey Steve, actually I assume there is not further trace into cifs, as acme shows this message by asking cifs about the filestatus, when putfile is called, as I showed in the putfile function. Symbolically the full call is: cmd/acme/exec.c:/put\(/ cmd/acme/exec.c:/putfile\(/ libc/9sys/dirstat.c:/dirstat\(/ which will call cmd/cifs/main.c:/fsstat\(/ to get the file status before writing the file. I will trace the actual values that are fetched from this fsstat call, but I wonder why noone else ever stumbled across this. IMHO, plan9 with acme is the most powerfull tool when working with multiple machines and cifs is useful for sharing across the different OSses in use in our days. I don't have any other problems with cifs and I use it daily too, but with acme, which is extremely useful to browse remote directories and to show several files or parts of them on one screen. If you want to see the problem yourself its quite easy: Just acme A_FILE_ON_YOUR_FAVOURITE_CIFS_SHARE Change something in that file and try to "Put" it back. And yes, I can't reproduce this error with sam. So the point of failure must be the code in acme! When I call cifs with -D I get the following trace from a test.txt that I load into acme to produce the wrong warning (I just show some P9 traces not all). 1. Open the file: -6-> Ropen tag 20 qid (75b35fd9e54fbee0 1411027197 ) iounit 0 -6-> Rstat tag 20 stat 'test.txt' 'bill' 'trog' 'boyd' q (75b35fd9e54fbee0 1411027197 ) m 0666 at 1411027176 mt 1411027197 l 500 t 67 d 4 2. Put the changes, 1st without a warning -6-> Ropen tag 38 qid (75b35fd9e54fbee0 1411027197 ) iounit 0 -6-> Rwrite tag 38 count 498 -6-> Rstat tag 38 stat 'test.txt' 'bill' 'trog' 'boyd' q (75b35fd9e54fbee0 1411027197 ) m 0666 at 1411027241 mt 1411027197 l 498 t 67 d 4 3. Try to Put another change, that shows the warning -6-> Rstat tag 39 stat 'test.txt' 'bill' 'trog' 'boyd' q (75b35fd9e54fbee0 1411027295 ) m 0666 at 1411027241 mt 1411027295 l 498 t 67 d 4 It seems here that the first write sequence leads to the error -6-> Ropen tag 38 qid (75b35fd9e54fbee0 1411027197 ) iounit 0 <-6- Tstat tag 38 fid 646 -6-> Rstat tag 38 stat 'test.txt' 'bill' 'trog' 'boyd' q (75b35fd9e54fbee0 1411027197 ) m 0666 at 1411027241 mt 1411027197 l 0 t 67 d 4 <-6- Twrite tag 38 fid 646 offset 0 count 498/* … */ -6-> Rwrite tag 38 count 498 <-6- Tstat tag 38 fid 646 -6-> Rstat tag 38 stat 'test.txt' 'bill' 'trog' 'boyd' q (75b35fd9e54fbee0 1411027197 ) m 0666 at 1411027241 mt 1411027197 l 498 t 67 d 4 as the stat after the write shows the same timestamp as the open (before the write), which seems wrong. When the file is changed in the acme buffer and should be put again, the stat reports the right timestamp from the first put, which leads to the warning. Regards Ingo Krabbe > Can you trace this a bit more into cifs? > > cifs is one of mine and I use it daily without problems, though I > never migrated from sam to acme, so perhaps I just don't see your issue. > > I remember that smb/cifs does have weird timestamps some of which are > only changed on 2 second boundries - though the code you show should > cope happily with that. > > The server has its own timestamp which cifs reads at startup and uses that > to convert the server's localtime to utc, but I think this time is read > only once per session so that is unlikely to be the problem. > > Sorry if I'am a bit vague but it was 10 years ago now, but I am happy to dig > if you can provide a bit more info. > > -Steve
