[9fans] Annyoing modified by boyd

[9fans] Annyoing modified by boyd

[Ingo Krabbe]

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+1<d->mtime){
			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

[Steve Simon]

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

Re: [9fans] Annyoing modified by boyd

[Ingo Krabbe]

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

Re: [9fans] Annyoing modified by boyd

[Steve Simon]

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

[Winston Kodogo]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

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 <steve@quintile.net> 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
>
>

[-- Attachment #2: Type: text/html, Size: 1369 bytes --]

Re: [9fans] Annyoing modified by boyd

[Ingo Krabbe]

> "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 <ikrabbe.ask@gmail.com> 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+1<d->mtime){
>>                         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

[Winston Kodogo]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

"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.

On 17 September 2014 23:18, Ingo Krabbe <ikrabbe.ask@gmail.com> 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+1<d->mtime){
>                         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
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2226 bytes --]