9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Ingo Krabbe <ikrabbe.ask@gmail.com>
To: <9fans@9fans.net>
Subject: Re: [9fans] Annyoing modified by boyd
Date: Thu, 18 Sep 2014 10:14:43 +0200	[thread overview]
Message-ID: <584d687a7d8676fa0b9afcf8764df136@krabbe.dyndns.org> (raw)
In-Reply-To: <ac37d4f164f37b4933f4e9ac7b69a828@quintile.net>

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





  reply	other threads:[~2014-09-18  8:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-17 11:18 Ingo Krabbe
2014-09-17 12:36 ` Steve Simon
2014-09-18  8:14   ` Ingo Krabbe [this message]
2014-09-18  9:09     ` Steve Simon
2014-09-18 21:46       ` Winston Kodogo
2014-09-18  3:41 Winston Kodogo
2014-09-18  8:20 ` Ingo Krabbe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=584d687a7d8676fa0b9afcf8764df136@krabbe.dyndns.org \
    --to=ikrabbe.ask@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).