Ask Klaus

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.

Figure 1: PCManFM gives a copy of a file the same timestamps as the original file.

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.