Alan McLachlan writes:
A write to a file will change the file size attribute in the directory entry, which will of course change the mod time on the directory itself.
No, it doesn't:
$ ls -ld temp temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 21 May 22 09:00 temp/foobar $ echo foobar >>temp/foobar $ ls -ld temp temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 28 May 22 15:19 temp/foobar
In fact, if you don't have "atime update" turned OFF, even opening a file will change the directory mod time since the access time attribute for the file needs to be updated in the directory entry.
No, it doesn't:
$ ls -ld temp; ls -ldu temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 28 May 22 15:17 temp/foobar $ cat temp/foobar Oh what a goose I am foobar $ ls -ld temp; ls -ldu temp/foobar drwxr-xr-x 2 cet1 cet1 4096 May 22 11:00 temp -rw-r--r-- 1 cet1 cet1 28 May 22 15:22 temp/foobar
(That was done on a different client from the previous test. Client-side caching can confuse attempts to look at atimes otherwise.)
Remember, in WAFL all metadata lives in files. That includes directories. So ANY change to a directory entry will cause the modification time on the directory to be updated.
But the directory entry doesn't change. It's the inode that changes. You seem to have confused the two.
This will in turn change the mod time on allrelevant parent directories up to the root.
Restate that as "the relevant block in the inode metafile has been changed, so all the index blocks up to the root have to be rewritten as well".
On a traditional filesystem likeNTFS or UFS this would be a performance disaster as it would generate lots of additional seeks, so they don't do it. However in WAFL an change to a file will cause all relevant metadata inodes up to the root inode to be rewritten [in new locations without seeks] anyway, without a performance cost.
All the changed blocks will (usually) be written close together as part of the next checkpoint. But none of these blocks are directory blocks, or blocks containing the inode for the directory (unless they happen to be the same block as that containing the inode for the file).
Hope this helps.
Honestly, I don't think it did.
Steve Losen wrote: ] ] My guess is that the application is doing more than a simple file open. ] Perhaps it is an editor that is creating a .bak file or something like ] that. As far as I know, to change the mod time of a directory (folder) ] you need to create, delete, or rename a file in the directory. Simply ] reading or writing an existing file does not change the directory mod ] time. An application could also explicitly set the mod time of the ] directory.
Another possibility is that the application is deleting and then re-creating the file, which would certainly change the mtime and ctime of the directory. Jeff Burton didn't make it very clear whether the "simple open" was for reading or writing.
] I can think of one other possibility, but I have doubts since this is ] a NTFS volume. If you create a directory with NFS, then it is not in ] unicode format (unless you specify an option to change this). ] The first time you access the directory via CIFS, it is converted to ] unicode, and this might also trip the directory mod time, but I don't ] know. Of course, this only happens once at the first CIFS access.
That obviously changes the directory contents, but does it change its mtime (or even the ctime)? I can't do that experiment here as we aren't licensed for CIFS access.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.