Allow btime to set any value or specify btime

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,


since Linux kernel 4.11, btime has been added, but there is no way to change btime to a logical behavior. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f

This behavior causes users to report errors in user space software. Based on this report.
https://bugzilla.redhat.com/show_bug.cgi?id=1919698

Users are using user space software in Fedora 33 or 34 and find it illogical how user space software and processes set btime.

Users expect:
- btime to be lower than mtime when the operating system is first installed - when files are changed, e.g. a .txt file in standard text editor, btime is no longer updated - btime is preserved when copying (file and directory) from source to destination


Unfortunately, the problem cannot be solved from userspace because only the Linux kernel is allowed to use btime.


As you can see in my answer there, I generally found out that there is no specification for btime in general.

https://pubs.opengroup.org/onlinepubs/009696699/basedefs/xbd_chap04.html#tag_04_07
https://pubs.opengroup.org/onlinepubs/007904875/functions/open.html

Further applies:

If O_CREAT is set and the file did not previously exist, upon successful completion, open() shall mark for update the st_atime, st_ctime, and st_mtime fields of the file and the st_ctime and st_mtime fields of the parent directory.

This means that ctime = mtime = atime applies when creating the file.


If there is no specification then it means that btime can be set from user space to any value. That would have been the expected behavior. Unfortunately the mistake was made to add btime since Linux kernel 4.11 without specifying it.

There are 2 direct solutions.

1)
Add the expected behavior, that means in the next Linux kernel version the kernel can set btime to any value, because btime was not specified. No specification means that there is no reason and this value can be set freely.

2)
btime will be removed from the official Linux kernel release until a specification in general exists. A proposal should be sent to the POSIX (or its successor) people to specify btime together.


My personal suggestion is as you can also see in my answers
https://bugzilla.redhat.com/show_bug.cgi?id=1919698#c5

- preserve btime when copying files and directories to the destination (this works for cabled transmissions and wireless transmissions) - setting the btime to any value in an existing file and directory (very important for rsync to make --crtimes command work) - if mtime, ctime and atime is set before btime, does not work there is an error message - if btime sets after mtime, ctime and atime, does not work there is an error message

The logic must always be that only the Linux kernel can use btime and btime must always be before mtime, ctime and atime.



https://bugzilla.redhat.com/show_bug.cgi?id=1919698#c7

Perhaps an additional solution is also important, the atime and mtime must not be changed from the user space more, but it works only with the Linux kernel.

The standard behavior should be more in line with the real world. My very old mother, who is already over 100 years old and therefore older than most operating systems. She finds Linux generally not harmonious, because Linux creates illogical timestamps for her documents. I also have very similar reasons and many of my friends see it the same way. This is also why all my family do not use Linux on a daily basis.





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux