From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <584d687a7d8676fa0b9afcf8764df136@krabbe.dyndns.org> To: <9fans@9fans.net> Date: Thu, 18 Sep 2014 10:14:43 +0200 From: Ingo Krabbe In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Annyoing modified by boyd Topicbox-Message-UUID: 16d963de-ead9-11e9-9d60-3106f5b1d025 Hey Steve, actually I assume there is not further trace into cifs, as acme shows thi= s 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=20 cmd/cifs/main.c:/fsstat\(/ to get the file status before writing the file. I will trace the actual v= alues 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 t= ool when working with multiple machines and cifs is useful for sharing ac= ross the different OSses in use in our days. I don't have any other problems with cifs and I use it daily too, but wit= h acme, which is extremely useful to browse remote directories and to sho= w 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 i= n 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=20 -6-> Rstat tag 20 stat 'test.txt' 'bill' 'trog' 'boyd' q (75b35fd9e54fbe= e0 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=20 -6-> Rwrite tag 38 count 498 -6-> Rstat tag 38 stat 'test.txt' 'bill' 'trog' 'boyd' q (75b35fd9e54fbe= e0 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 (75b35fd9e54fbe= e0 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=20 <-6- Tstat tag 38 fid 646 -6-> Rstat tag 38 stat 'test.txt' 'bill' 'trog' 'boyd' q (75b35fd9e54fbe= e0 1411027197 ) m 0666 at 1411027241 mt 1411027197 l 0 t 67 d 4 <-6- Twrite tag 38 fid 646 offset 0 count 498 /* =E2=80=A6 */ -6-> Rwrite tag 38 count 498 <-6- Tstat tag 38 fid 646 -6-> Rstat tag 38 stat 'test.txt' 'bill' 'trog' 'boyd' q (75b35fd9e54fbe= e0 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 w= arning. Regards Ingo Krabbe > Can you trace this a bit more into cifs? >=20 > 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= . >=20 > 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. >=20 > The server has its own timestamp which cifs reads at startup and uses t= hat > 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. >=20 > Sorry if I'am a bit vague but it was 10 years ago now, but I am happy t= o dig > if you can provide a bit more info. >=20 > -Steve