Klaus Knopper answers your Linux questions
Ask Klaus
Understanding and taming file timestamps.
Keeping Time
Hello, Klaus: A number of file manager apps such as Dolphin, PCManFM, and Thunar do not preserve a file's timestamp when copying it between filesystems. I'm trying to configure Debian 8.2.0 to do this and have found that if the filesystem I'm copying to is mounted on startup (i.e., specified in /etc/fstab
), the timestamp is not preserved when copying; the current system time is substituted.
However, if I remove the line from fstab
, reboot, have Dolphin mount it dynamically (putting it in /media/<myname>/<DiskUUID>
), and then copy the file, the timestamp is preserved.
I assumed that it must be because of different timestamp-related mount options, such as atime
, relatime
, and so on, so I have tried several of these in the fstab
line for that filesystem. The mount
command shows that the option I tried is in effect, but the timestamp behavior does not change.
I tried copying from a shell and found the same behavior, unless I ran the copy command as root and gave it the specific option to force timestamp preservation. That's not an option in graphical file managers.
I've searched the forums and have found several discussions about it, but they're all several years old. They, like I, consider it a fairly serious bug, as a file timestamp can be important. But I didn't find any workaround, just "we're working on it."
Most of the filesystems I used for testing this are NTFS data drives on a dual-boot Windows/Linux system, but I've found the same behavior on a Linux filesystem – ext4 if I remember right.
I'm using Debian 8.2.0 currently but have found this on the last several Kubuntu releases as well (since 14.04 LTS). I tried it with my Knoppix USB drive, but to preserve portability, it mounts everything but its own root filesystem dynamically, so isn't an apples-to-apples comparison.
Is there a fix/workaround for this (besides mounting everything dynamically, which isn't a good option for me, because I have startup stuff that depends on files on those filesystems)? And why in the world isn't preservation of timestamps the default behavior when the bug has been known for so long?!
Any help is appreciated – thanks very much.
Gary Rathbun
Hi Gary:
I agree in part that a file's creation, modification, and access timestamp, as well as other metadata such as extended attributes and permissions, are valuable information. The modification timestamp, especially, is useful to sort files in order of last modification (ls -lrt
).
However, to me it makes more sense to have a file's copy timestamp set to the current time (i.e., the new file's creation time), rather than setting timestamps back in time to that of the original file – except for archives and backups, for which you want to preserve all meta-information in case the original file gets lost. This is the default behavior of the Unix cp
command. For preserving all file attributes, you would use the "archive" option -a
, which you already found.
Some file managers associate command lines with copying, renaming, and removing files, but without a choice of options. Others implement their own version of file copying to better trace data transfer progress. All writable filesystems, including FAT32, support "file creation time," so even the noatime
or relatime
mount options are irrelevant if the destination file is newly created or overwritten, unless the modification time (as part of the metadata) is being changed after closing the file.
The copy procedure used in the file manager entirely determines how metadata is treated.
Looking into the source code of PCManFM, I found what you see in Listing 1 in the libfm/src/job/fm-file-ops-job-xfer.c
file. The default option in PCManFM is indeed to set the metadata (including timestamps) of the destination to that of the original file (Figure 1). Personally, I would prefer the copy to have a timestamp containing the time the copy was made, but that's not what PCManFM does.
Listing 1
Excerpt from PCManFM Source Code
The question remains why the timestamps are not set on filesystems that have not been mounted by the user. Looking at the mount options listed in /proc/mounts
does not provide any obvious hints; however, when root mounts a filesystem, certain file operations, such as modifying owner and group or extended file attributes, may be protected and not allowed for an unprivileged user. FAT32 and NTFS, which don't support the Unix owner/group/permission systems, especially depend on the user
option for mounting the filesystem with permissive settings (so that it looks like every file and directory is owned by the unprivileged user).
Even if setting the timestamp is not among the privileged file operations, it may be that a complete set of metadata operations fails in its entirety; for example, if PCManFM tries to reset the file permissions and fails because it is only allowed if the user owns the mountpoint, then the file date setting may be – wrongly – skipped. It's not directly related to the *time
mount options, but rather to the permissions determined by the root- or user-mounted mountpoint (mount option user
in /etc/fstab
or mounting via pmount
or udisks/policykit
in the file manager).
This matches your observations.
In summary, the file manager implementation is what determines which metadata is copied with the file; the kernel root, rather than user, access mode for the mounted filesystem is what determines which metadata can be set and which can't, possibly leaving the rest of the metadata unchanged as well if one operation fails.
Modifying this behavior would require changes to and recompilation of the file manager source code so that, perhaps, the file manager would try to set different types of metadata one by one, ignoring a permission failure for one type when attempting to set the others.
Klaus Knopper
Klaus Knopper is an engineer, creator of Knoppix, and co-founder of LinuxTag expo. He works as a regular professor at the University of Applied Sciences, Kaiserslautern, Germany. If you have a configuration problem, or if you just want to learn more about how Linux works, send your questions to: klaus@linux-magazine.com
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Fedora 39 Beta is Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.
-
Star Labs Reveals a New Surface-Like Linux Tablet
If you've ever wanted a tablet that rivals the MS Surface, you're in luck as Star Labs has created such a device.
-
SUSE Going Private (Again)
The company behind SUSE Linux Enterprise, Rancher, and NeuVector recently announced that Marcel LUX III SARL (Marcel), its majority shareholder, intends to delist it from the Frankfurt Stock Exchange by way of a merger.