有没有什么可能的情况
ls -l file.txt
显示的字节数与
wc -c file.txt
在一个脚本中，我发现了这两个值的比较。那可能是什么原因？甚至可能有同一个文件的不同字节数吗？
我总是假设/ ... 系统调用st_blocks返回的字段用于获取文件的磁盘使用情况以 512 字节为单位表示。stat()lstat()du
检查POSIX 规范，我现在看到 POSIX 对此没有做出保证。其自身功能的文档perlstat()也警告不要做出这种假设。
无论如何，正如 POSIX 所指示的，该块大小与st_blksize返回的字段无关stat()，因此必须在其他地方找到。
检查 GNUdu或 GNUfind源代码，我看到 HP/UX 使用 1024 字节单位的证据。GNUfind调整其-printf %b输出以始终提供多个 512 字节单位，这可能是我困惑的根源。
目前是否还有其他仍在使用的类 Unix 系统st_blocks不是以 512 字节为单位表示的？这可以依赖于文件系统吗（正如 POSIX 所建议的那样）？我想安装 HP/UX NFS 共享可以做到这一点。
如何仅在某个文件超过定义的大小时才执行命令？两者最终都应该作为 crontab 中的单行代码运行。
伪代码：
* * * * * find /cache/myfile.csv -size +5G && echo "file is > 5GB"
我试图了解原因wc并stat报告不同的事情/proc/[pid]/cmdline。
wc说我的 shellcmdline文件大小为 6 个字节：
$ wc --bytes /proc/$$/cmdline
6 /proc/10425/cmdline
stat表示文件大小为 0 字节：
$ stat --format='%s' /proc/$$/cmdline
0
file同意stat：
$ file /proc/$$/cmdline
/proc/10425/cmdline: empty
cat给出这个输出：
$ cat -vE /proc/$$/cmdline
-bash^@
所有这些都在 Linux 上进行，而不是在任何其他 *nix 操作系统上进行。
stat和程序是否wc有不同的算法来计算文件中的字节数？