[9fans] curious mtime of cwfs

[9fans] curious mtime of cwfs

[arisawa]

Hello,

cwfs64x shows curious mtime in dump.
my experiment is only on cwfs64x. I don't know other cwfs.
fossil is OK.

standing on general rule of unix and plan9,
mtime of directory should be the time that the contents are modified.


#
#	fossil
#

ar% ls -ld /n/dump
d-r-xr-xr-x M 538590 adm adm 0 Dec 31  2003 /n/dump/2003
d-r-xr-xr-x M 538590 adm adm 0 Dec 31  2004 /n/dump/2004
d-r-xr-xr-x M 538590 adm adm 0 Dec 31  2005 /n/dump/2005
d-r-xr-xr-x M 538590 adm adm 0 Dec 31  2006 /n/dump/2006
d-r-xr-xr-x M 538590 adm adm 0 Dec 31  2007 /n/dump/2007
d-r-xr-xr-x M 538590 adm adm 0 Dec 31  2008 /n/dump/2008
d-r-xr-xr-x M 538590 adm adm 0 Dec 31  2009 /n/dump/2009
d-r-xr-xr-x M 538590 adm adm 0 Dec 30  2010 /n/dump/2010
d-r-xr-xr-x M 538590 adm adm 0 Dec 31  2011 /n/dump/2011
d-r-xr-xr-x M 538590 adm adm 0 Dec 31 13:00 /n/dump/2012
d-r-xr-xr-x M 538590 adm adm 0 Feb 24 13:00 /n/dump/2013
ar% ls -ld /n/dump
d-r-xr-xr-x M 538590 adm adm 0 Jan  1 13:00 /n/dump
ar% ls -l /n/dump/2013
...
d-r-xr-xr-x M 538590 adm adm 0 Feb 20 13:00 /n/dump/2013/0220
d-r-xr-xr-x M 538590 adm adm 0 Feb 21 13:00 /n/dump/2013/0221
d-r-xr-xr-x M 538590 adm adm 0 Feb 22 13:00 /n/dump/2013/0222
d-r-xr-xr-x M 538590 adm adm 0 Feb 23 13:00 /n/dump/2013/0223
d-r-xr-xr-x M 538590 adm adm 0 Feb 24 13:00 /n/dump/2013/0224
ar% ls -ld /n/dump/2013
d-r-xr-xr-x M 538590 adm adm 0 Feb 24 13:00 /n/dump/2013
# this is OK because the last change is at  the time 0224 is added.
ar%


#
#	cwfs64x
#

maia# ls -l /n/dump
d-r-xr-xr-x M 160 adm adm 0 Aug  1  2012 /n/dump/2012
d-r-xr-xr-x M 160 adm adm 0 Jan 21 05:07 /n/dump/2013
maia# ls -ld /n/dump
d-r-xr-xr-x M 160 adm adm 0 Jul 31  2012 /n/dump
maia# ls -l /n/dump/2013
....
d-r-xr-xr-x M 160 adm adm 0 Feb 21 05:00 /n/dump/2013/0221
d-r-xr-xr-x M 160 adm adm 0 Feb 22 05:00 /n/dump/2013/0222
d-r-xr-xr-x M 160 adm adm 0 Feb 23 00:23 /n/dump/2013/0223
d-r-xr-xr-x M 160 adm adm 0 Feb 24 05:00 /n/dump/2013/0224
d-r-xr-xr-x M 160 adm adm 0 Feb 24 17:09 /n/dump/2013/02241
d-r-xr-xr-x M 160 adm adm 0 Feb 25 05:00 /n/dump/2013/0225
maia# ls -ld /n/dump/2013
d-r-xr-xr-x M 160 adm adm 0 Jan 21 05:07 /n/dump/2013
# this is NG because the last change is at  the time 0225 is added.
maia#

Kenji Arisawa

Re: [9fans] curious mtime of cwfs

[arisawa]

sorry

- # this is NG because the last change is at  the time 0225 is added.
+ # this is NG because the last change should be at  the time 0225 is added.

Kenji Arisawa

Re: [9fans] curious mtime of cwfs

[cinap_lenrek]

yes. very good observation. the following change fixes it for me (with added comments)

term% hg diff -r 1763 cw.c
diff -r 5229de0742e8 sys/src/cmd/cwfs/cw.c
--- a/sys/src/cmd/cwfs/cw.c	Tue Jul 24 19:42:18 2012 +0200
+++ b/sys/src/cmd/cwfs/cw.c	Mon Feb 25 06:30:55 2013 +0100
@@ -1557,14 +1557,13 @@
 	d1->uid = d->uid;
 	d1->gid = d->gid;
 	putbuf(p);
-	accessdir(p1, d1, FWRITE, 0);	<- was modifying yyyy direcoty in case when added, will do below instead
+	accessdir(pr, dr, FWRITE, 0);	<- update mtime of dumproot as we added yyyy directory

 	/*
 	 * put mmdd[count] in year directory
 	 */
 found2:
-	accessdir(p1, d1, FREAD, 0);	<- was updating atime of yyyy direcotory in case when it was already present. this is not needed as we'r going to always update both atime and mtime below
-	p1->flags |= Bmod;	/* noatime */
+	accessdir(pr, dr, FREAD, 0);	<- update atime of dumproot only as we didnt add a new yyyy direcotory
 	putbuf(pr);
 	pr = p1;						<- yyyy directory become pr/dr
 	dr = d1;
@@ -1603,6 +1602,7 @@
 	d1->qid.version += n;
 	accessdir(p1, d1, FWRITE, 0);	<- update dump sub directory times
 	putbuf(p1);
+	accessdir(pr, dr, FWRITE, 0);	<- now update atime and mtime of yyyy directory after creating dump sub directory in it
 	putbuf(pr);

 	cw->fsize = cwsize(cw->dev);

the problem was that we only updated mtime of the yyyy directory when
we newly created it, otherwise only access time was updated. but we
*always* have to update mtime of the yyyy directory because we are
modifying it by creating the dump sub directory in it.

--
cinap

Re: [9fans] curious mtime of cwfs

[arisawa]

Hello sinap,

thank you for your quick fix.
your patches work also for me.

however the problem is not only in dump but (I think) in all directories of cwfs.

#
#	fossil
#
ar% ls -lt
--rw-r--r-- M 546403 arisawa arisawa  1123 Apr  3  2001 a.c
--rwxrwxr-x M 546403 arisawa arisawa 39276 Mar 31  2001 8.out
--rw-rw-r-- M 546403 arisawa arisawa  4559 Mar 31  2001 a.8
--rw-r--r-- M 546403 arisawa arisawa   248 Mar 31  2001 mkfile
ar% ls -ld .
d-rwxrwxrwx M 546403 arisawa arisawa 0 Aug  5  2002 wrk
ar% touch a.c
ar% ls -ld .
d-rwxrwxrwx M 546403 arisawa arisawa 0 Feb 25 16:02 wrk
# this is OK because the directory  is updated
ar% 

#
#	cwfs
#
maia# ls -lt
--rw-rw-r-- M 20 arisawa arisawa 43320 Feb 25 15:50 cw.c
d-rwxrwxr-x M 20 arisawa arisawa     0 Feb 17 17:43 cwfs64x
...
maia# ls -ld .
d-rwxrwxr-x M 20 arisawa arisawa 0 Sep 11 14:17 cwfs
# NG because cw.c updated this time.
maia#

Kenji Arisawa

On 2013/02/25, at 14:55, cinap_lenrek@gmx.de wrote:

> yes. very good observation. the following change fixes it for me (with added comments)
> 
> term% hg diff -r 1763 cw.c
> diff -r 5229de0742e8 sys/src/cmd/cwfs/cw.c
> --- a/sys/src/cmd/cwfs/cw.c	Tue Jul 24 19:42:18 2012 +0200
> +++ b/sys/src/cmd/cwfs/cw.c	Mon Feb 25 06:30:55 2013 +0100
> @@ -1557,14 +1557,13 @@
> 	d1->uid = d->uid;
> 	d1->gid = d->gid;
> 	putbuf(p);
> -	accessdir(p1, d1, FWRITE, 0);	<- was modifying yyyy direcoty in case when added, will do below instead
> +	accessdir(pr, dr, FWRITE, 0);	<- update mtime of dumproot as we added yyyy directory
> 
> 	/*
> 	 * put mmdd[count] in year directory
> 	 */
> found2:
> -	accessdir(p1, d1, FREAD, 0);	<- was updating atime of yyyy direcotory in case when it was already present. this is not needed as we'r going to always update both atime and mtime below
> -	p1->flags |= Bmod;	/* noatime */
> +	accessdir(pr, dr, FREAD, 0);	<- update atime of dumproot only as we didnt add a new yyyy direcotory
> 	putbuf(pr);
> 	pr = p1;						<- yyyy directory become pr/dr
> 	dr = d1;
> @@ -1603,6 +1602,7 @@
> 	d1->qid.version += n;
> 	accessdir(p1, d1, FWRITE, 0);	<- update dump sub directory times
> 	putbuf(p1);
> +	accessdir(pr, dr, FWRITE, 0);	<- now update atime and mtime of yyyy directory after creating dump sub directory in it
> 	putbuf(pr);
> 
> 	cw->fsize = cwsize(cw->dev);
> 
> the problem was that we only updated mtime of the yyyy directory when
> we newly created it, otherwise only access time was updated. but we
> *always* have to update mtime of the yyyy directory because we are
> modifying it by creating the dump sub directory in it.
> 
> --
> cinap
> 

Re: [9fans] curious mtime of cwfs

[cinap_lenrek]

i'm not sure. if you touch an existing file, then it makes sense
that the files mtime gets updated, not the whole directory.

wstat() and write() on a file only update the files mtime, not
the parent directory.

however creating a new file or deleting a file from a directory
does change the directories mtime. (the dump change makes it
consistent with that).

--
cinap

Re: [9fans] curious mtime of cwfs

[arisawa]

the role of directory mtime of plan9 is ambiguous for me.
that need not be same as that of unix because plan9 does not have ctime.
is there the specification?

by the way, directory atime is also difficult to understand.
the time is really useful?
readdir() returns 0 although cwfs has the value.

Kenji Arisawa

On 2013/02/25, at 17:23, cinap_lenrek@gmx.de wrote:

> i'm not sure. if you touch an existing file, then it makes sense
> that the files mtime gets updated, not the whole directory.
>
> wstat() and write() on a file only update the files mtime, not
> the parent directory.
>
> however creating a new file or deleting a file from a directory
> does change the directories mtime. (the dump change makes it
> consistent with that).
>
> --
> cinap
>

Re: [9fans] curious mtime of cwfs

[Anthony Martin]

cinap_lenrek@gmx.de once said:
> i'm not sure. if you touch an existing file, then it makes sense
> that the files mtime gets updated, not the whole directory.
>
> wstat() and write() on a file only update the files mtime, not
> the parent directory.
>
> however creating a new file or deleting a file from a directory
> does change the directories mtime. (the dump change makes it
> consistent with that).

>From stat(5):

    For a plain file, mtime is the time of the most recent
    create, open with truncation, or write; for a directory
    it is the time of the most recent remove, create, or
    wstat of a file in the directory.

Cheers,
  Anthony

Re: [9fans] curious mtime of cwfs

[cinap_lenrek]

that means kenfs/cwfs and kfs are doing wstat wrong.

--
cinap

Re: [9fans] curious mtime of cwfs

[arisawa]

thanks Anthony,

I understand the behavior of fossil.
cwfs is out of the rule.

I said:
  standing on general rule of unix and plan9,
  mtime of directory should be the time that the contents are modified.
but this is not true in rigorous speaking.

Kenji Arisawa

On 2013/02/25, at 19:34, Anthony Martin <ality@pbrane.org> wrote:

> cinap_lenrek@gmx.de once said:
>> i'm not sure. if you touch an existing file, then it makes sense
>> that the files mtime gets updated, not the whole directory.
>>
>> wstat() and write() on a file only update the files mtime, not
>> the parent directory.
>>
>> however creating a new file or deleting a file from a directory
>> does change the directories mtime. (the dump change makes it
>> consistent with that).
>
> From stat(5):
>
>    For a plain file, mtime is the time of the most recent
>    create, open with truncation, or write; for a directory
>    it is the time of the most recent remove, create, or
>    wstat of a file in the directory.
>
> Cheers,
>  Anthony
>

Re: [9fans] curious mtime of cwfs

[erik quanstrom]

>  From stat(5):
>
>     For a plain file, mtime is the time of the most recent
>     create, open with truncation, or write; for a directory
>     it is the time of the most recent remove, create, or
>     wstat of a file in the directory.

does this apply to synthetic file servers as well?  does any
one know the reasoning behind this change?  at first
glance, it seems like a relatively large impact considering
the potential gain.

- erik

Re: [9fans] curious mtime of cwfs

[arisawa]

Hell erik,

Thanks for your attention.

I looked old Plan 9 manual ver.2.
The quoted portion of stat(5) is not changed since that time.

Plan 9 does not have ctime.
If the directory mtime is not updated in changing wstat info,
It will be bothersome to detect changes in permission etc since given time.
And in addition, if cwfs works same as manual, we can quickly get correct info of changes in each dump.

Kenji Arisawa

On 2013/03/03, at 6:08, erik quanstrom <quanstro@labs.coraid.com> wrote:

>> From stat(5):
>> 
>>    For a plain file, mtime is the time of the most recent
>>    create, open with truncation, or write; for a directory
>>    it is the time of the most recent remove, create, or
>>    wstat of a file in the directory.
> 
> does this apply to synthetic file servers as well?  does any
> one know the reasoning behind this change?  at first
> glance, it seems like a relatively large impact considering
> the potential gain.
> 
> - erik
>