Project

General

Profile

Actions
Copy link

Bug #3251

closed

file ctime not updated as documented on chmod(), link()

Added by tonyc about 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
VFS subsystem
Target version:
-
Start date:
10/26/2020
Due date:
02/18/2021
% Done:

100%

Estimated time:

Description

The stat(2) man page claims:

st_ctim       Time when file status was last changed (inode data
                   modification).  Changed by the chmod(2), chown(2), link(2),
                   mknod(2), rename(2), unlink(2), utimes(2) and write(2)
                   system calls.

but neither link() nor chmod() update ctim.tv_sec:

$ pwd
  /home/tony/dev/perl/git/dflybugs
  $ cc -olink_ctime link_ctime.c
  $ ./link_ctime
  FAIL: chmod didn't update ctime
  FAIL: link didn't update ctime
  $ mount
  serno/VB6e53d937-50b8dc58.s1d on / (hammer2, local)
  devfs on /dev (devfs, nosymfollow, local)
  /dev/serno/VB6e53d937-50b8dc58.s1a on /boot (ufs, local)
  /build/usr.obj on /usr/obj (null)
  /build/var.crash on /var/crash (null)
  /build/var.cache on /var/cache (null)
  /build/var.spool on /var/spool (null)
  /build/var.log on /var/log (null)
  /build/var.tmp on /var/tmp (null)
  tmpfs on /tmp (tmpfs, local)
  procfs on /proc (procfs, local)
  tmpfs on /var/run/shm (tmpfs, local)
  $ uname -a
  DragonFly  5.8-RELEASE DragonFly v5.8.3-RELEASE #10: Thu Sep 24 19:19:45 EDT 2020     :/usr/obj/home/justin/release/5_8/sys/X86_64_GENERIC  x86_64

link_ctime.c is attached.

Files

link_ctime.c (1.12 KB) link_ctime.c tonyc, 10/25/2020 06:00 PM
Actions
Copy link
 #1

Updated by deef almost 4 years ago

  • Due date set to 12/22/2020
  • Status changed from New to In Progress
  • % Done changed from 0 to 50

link() issue fixed for both hammer (commit c5adbbb2+ on master, d74465f2+ on RELEASE_5_8) and hammer2 (b6c0d52e+ master, 2d476770+ RELEASE_5_8).

However, I've been unable to reproduce chmod() issue... It works as expected for me on master. And according to the code, it should also work the same on RELEASE_5_8. Could anybody confirm, please? :)

Actions
Copy link
 #2

Updated by tonyc almost 4 years ago

deef wrote:

However, I've been unable to reproduce chmod() issue... It works as expected for me on master. And according to the code, it should also work the same on RELEASE_5_8. Could anybody confirm, please? :)

My test is a little broken in that it doesn't distinguish between a successful chmod() that does change the mode and a successful chmod() doesn't change the mode, but I'm not sure that makes a difference.

Looking at the code (HEAD:/sys/vfs/hammer2/hammer2_vnops.c#l543) it appears ctime is only updated when the mode is modified. The dragonfly man pages that I (briefly) looked at don't include enough information to decide whether that's documented behaviour, but POSIX says:

Upon successful completion, chmod() shall mark for update the last file status change timestamp of the file.

So it looks to me like POSIX says that ctime should be modified even if the mode doesn't actually change. This is the behaviour on Linux/ext4 and FreeBSD 11.4/ufs.

Actions
Copy link
 #3

Updated by deef almost 4 years ago

  • Due date changed from 12/22/2020 to 02/18/2021
  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100

Also chmod() should now behave POSIXly :), for both hammer (commit cf4606c+ on master, 11e11aa+ on RELEASE_5_8) and hammer2 (787d144+ on master, d96b57b+ on RELEASE_5_8).

Actions
Copy link

Also available in: Atom PDF