[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

[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

[c***@gmx.de]

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

[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

Post by c***@gmx.de
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
*/
- 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

[c***@gmx.de]

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

[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

Post by c***@gmx.de
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

[Anthony Martin]

Post by c***@gmx.de
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

[c***@gmx.de]

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

--
cinap

[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

Post by Anthony Martin

Post by c***@gmx.de
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).

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

[erik quanstrom]

Post by Anthony Martin
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

[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

Post by erik quanstrom

Post by Anthony Martin
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