stat: --printf option does not support precision in certain format strings

[jfinkels]

The --printf argument to stat does not seem to correctly support precision specifiers in format strings.

For example, after creating a file with touch f...

GNU stat:

$ stat --printf='%.1Y\n' f
1646795086.4

uutils stat:

$ ./target/release/stat --printf='%.1Y\n' f
1

From the documentation

The ‘%W’, ‘%X’, ‘%Y’, and ‘%Z’ formats accept a precision preceded by a period to specify the number of digits to print after the decimal point. For example, ‘%.3X’ outputs the access timestamp to millisecond precision. If a period is given but no precision, stat uses 9 digits, so ‘%.X’ is equivalent to ‘%.9X’. When discarding excess precision, timestamps are truncated toward minus infinity.

-- https://www.gnu.org/software/coreutils/manual/html_node/stat-invocation.html

[sergeevabc]

@jfinkels, err… Where did you find stat in this package? That's what I see on Windows 7 x64 upon launch of coreutils 0.0.16

$ coreutils.exe
coreutils 0.0.16 (multi-call binary)

Usage: coreutils [function [arguments...]]                                                      
                                                                                                
Currently defined functions:                                                                    
                                                                                                
    [, arch, b2sum, b3sum, base32, base64, basename, basenc, cat, cksum, comm, cp, csplit, cut, 
    date, dd, df, dir, dircolors, dirname, du, echo, env, expand, expr, factor, false, fmt,     
    fold, hashsum, head, hostname, join, link, ln, ls, md5sum, mkdir, mktemp, more, mv, nl,     
    nproc, numfmt, od, paste, pr, printenv, printf, ptx, pwd, readlink, realpath, relpath, rm,  
    rmdir, seq, sha1sum, sha224sum, sha256sum, sha3-224sum, sha3-256sum, sha3-384sum, sha3-     
    512sum, sha384sum, sha3sum, sha512sum, shake128sum, shake256sum, shred, shuf, sleep, sort,  
    split, sum, sync, tac, tail, tee, test, touch, tr, true, truncate, tsort, unexpand, uniq,   
    unlink, vdir, wc, whoami, yes

$ coreutils.exe stat
stat: function/utility not found                                                             

[tertsdiepraam]

@sergeevabc It's not available on Windows. If you're on unix, you can compile with --features unix or --features stat to access it.

[tertsdiepraam]

Even though it was supposed to be only a refactor, https://github.com/uutils/coreutils/pull/4150 solves part of this:

$ cargo run --quiet -- stat --printf='%.1Y\n' f
1668645806

At least it shows some useful info and not just 1 😄 I think the problem is that the precision is misinterpreted as the length of the string instead of the digits after the decimal point or something like that.

[Kev1n8]

I've dug into this issue and found that the implementation of stat does not care about type float. Furthermore, the function used to get meta info of files fs::symlink_metadata or fs::metadata returns values no more than type integer or unsigned in the first place. So I suppose fixing this would require another dependency such as filetime for higher precision. @tertsdiepraam