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
