Author: Wu Feixiang

Soft link causes a dead card problem

fs::symlink_metadata

Recently written recursive search folder statistics size program, measure a folder size hours card dead

Use find-type L to search for soft links and find two link loops: a points to b’s folder while B points to A’s folder

STD ::fs::metadata calls stat() system calls follow links

Symlink_metadata is lstat()

errno 40 ELOOP

Linux gliBC error code Errno 40(ELOOP) Indicates that the number of soft link hops is too many.

Thinking the standard library would give ELOOP errors, wildcat teacher said that STD :: FS made a lot of sacrifices in order to be cross-platform

(As if STD :: FS apis don’t handle ELOOP error codes? But I’ve never seen one. Errno ELOOP.)

Is_symlink () always returns false?

Trade-offs made by the standard library for cross-platform purposes such as is_syslink() of Metadata () always returning false are clearly not well designed for Linux systems

Since metadata/stat “eats” the soft link, parsing it into a normal file means that the abstraction of the soft link is gone

So metadata().is_symlink() must always return false on Linux

So Rust documentation is nice enough to note that is_symlink() is only valid if used with symlink_metadata()

The only way to know if a file is a soft link is to use symlink_metadata/lstat to not track soft links

Of course, the MAN document must also have hints, but I was looking at the TLDR too long did not look carefully…

Is_symlink and is_dir are mutually exclusive

In the return value of symlink_metadata()/lstat()

Is_symlink () and is_dir() are mutually exclusive only if one is true and the other is false

Is_symlink doesn’t have stable yet.

I have to say that the standard library support for various Linuxexts is quite lacking, is_Symlink is expected to be stable in early 2022

Metadata member fields are all private, so transmute or find UnixExt

// Linux ::fs::MetadataExt
let st_mode = std::os::linux::fs::MetadataExt::st_mode(&metadata);

// Mute
let st_mode = unsafe { std::mem::transmute::<_, libc::mode_t>(metadata.file_type()) };

// Call libc::stat or libc::lstat
Copy the code

Metadata::len(

Hard Disk 4K Alignment

For example, a.table has only one character, stat command or fs::Metadata::len() to see that the size is exactly 1

Linux ext4 file systems are usually block-sized in 4K

The minimum storage unit of the hard disk is 4K, and all files occupy an integer multiple of 4K space on the hard disk

A bit like the internal memory layout should be aligned with the CPU register size of 8 bytes, and the structure size should be an integer multiple of 8 bytes

If du is specified with a block-size argument such as du –apparent-size –block-size 1, it is the same as stat

Du –bytes or du-b is short for du –apparent — size –block-size 1

Is /proc really zero size

/dev, /proc, and /sys are virtual file systems with zero size on the hard disk.

Most of the files in the three folders are zero size, but “/proc/bus/pci/00/01.2”, for example, has a size

For example, “/proc/config.gz” stores the compile-time parameters of the Linux kernel

Many of the parameters are strings, so zcat comes out with “variable” or indeterminate lengths

So stat just says what the length of /proc/config.gz would have been if it had been read at the current time

[w@ww repos]$ stat /proc/config.gz File: /proc/config.gz Size: 58526 Blocks: 0 IO Block: 1024 regular file Device: 0,21 Inode: 4026532079 Links: 1 Access: (0444/-r--r--r--) Uid: (0 / root) Gid: (0 / root) Access: 2021-11-08 21:11:50.742480314 +0800 Modify: 2021-11-08 21:11:50.742480314 +0800 Change: 2021-11-08 21:11:50.742480314 +0800 Birth: - [w@ww repos]$du /proc/config.gz 0 /proc/config.gzCopy the code