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 ti
> 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
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
that means kenfs/cwfs and kfs are doing wstat wrong.
--
cinap
cinap_len...@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 f
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.
K
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 directo
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
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 +1
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
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
11 matches
Mail list logo
