Bug 15622 - mv timestamp awkward behaviour
Summary: mv timestamp awkward behaviour
Status: NEW
Alias: None
Product: Busybox
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.35.x
Hardware: All Linux
: P5 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-06-06 14:21 UTC by JM Friedt
Modified: 2023-06-10 09:57 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:

Attachments
busybox configuration file (31.64 KB, application/octet-stream)
2023-06-06 14:21 UTC, JM Friedt 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description JM Friedt 2023-06-06 14:21:35 UTC 
Created attachment 9604 [details]
busybox configuration file

I need to remember a file last access with sub-second accuracy. On a Raspberry Pi4 running Buildroot 2022.08.1 (raspberrypi4_64_defconfig) using Busybox 1.35.0:
1. create a file on the /tmpfs of the Raspberry Pi 4

TWSTFT:13:44# touch toto
TWSTFT:13:44# stat toto
  File: toto
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 13h/19d Inode: 10525       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-06-06 13:44:44.804197892 +0000
Modify: 2023-06-06 13:44:44.804197892 +0000
Change: 2023-06-06 13:44:44.804197892 +0000

All times are given with ns resolution.
When moving the file using Busybox's mv from /tmp (tmpfs) to an external hard disk formatted in EXT4:

TWSTFT:13:44# cd /root/data/
TWSTFT:13:44# mv /tmp/toto .
TWSTFT:13:45# stat toto
  File: toto
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 801h/2049d      Inode: 303         Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-06-06 13:44:44.000000000 +0000
Modify: 2023-06-06 13:44:44.000000000 +0000
Change: 2023-06-06 13:45:02.224085953 +0000

The Access and Modify times are now truncated to one-second resolution. If on the same HDD I create a file

TWSTFT:13:45# touch hdd
TWSTFT:13:45# stat hdd
  File: hdd
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 801h/2049d      Inode: 304         Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-06-06 13:45:11.468026512 +0000
Modify: 2023-06-06 13:45:11.468026512 +0000
Change: 2023-06-06 13:45:11.468026512 +0000

the statistics with full resolution are kept. Is this a bug in mv or a feature?

Thanks.
Comment 1 JM Friedt 2023-06-10 09:57:57 UTC 
This appears to be due to
                times[1].tv_sec = times[0].tv_sec = source_stat.st_mtime; 
                times[1].tv_usec = times[0].tv_usec = 0;
in libbb/copy_file.c in 
int FAST_FUNC copy_file(const char *source, const char *dest, int flags)
which sets the fractional part of the time to 0 irrelevant of the selected options.

Is this behaviour expected when coreutils/stat.c states
static const char *human_time(struct timespec *ts)
{
        char fmt[sizeof("%Y-%m-%d %H:%M:%S.123456789 %z") + /*paranoia*/ 8];

        /* coreutils 6.3 compat */
#define buf bb_common_bufsiz1
        setup_common_bufsiz();

        sprintf(stpcpy(fmt, "%Y-%m-%d %H:%M:%S"), ".%09u %%z", (unsigned)ts->tv_nsec);
        strftime(buf, COMMON_BUFSIZE, fmt, localtime(&ts->tv_sec));
        return buf;
#undef buf
}
able to cope with sub-second resolution?