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
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.
-
DebConf24 to be Held in South Korea
Busan will be the location of the latest DebConf running July 28 through August 4
-
Fedora Unleashes Atomic Desktops
Fedora has combined its solid distribution with rpm-ostree system to make it possible to deliver a new family of Fedora spins, called Fedora Atomic Desktops.
-
Bootloader Vulnerability Affects Nearly All Linux Distributions
The developers of shim have released a version to fix numerous security flaws, including one that could enable remote control execution of malicious code under certain circumstances.