File Identity and Metadata

Linux FoundationsLesson 4 of 945 minutesLessonBuilds on: Navigating the FilesystemLab next: Filesystem Lab

The question: can you trust a filename?

A filename can suggest a file’s type, but it doesn’t establish its contents. Linux doesn’t require a .txt suffix on text, and there’s nothing at all stopping anyone from naming a directory report.pdf.

A directory stores names, and those names refer to filesystem objects. A person or a program picks them, so a name can be helpful, misleading, or completely ridiculous. The filesystem keeps metadata about the object itself, stored separately from the name, and that covers its type, its size, its owner, its permission mode, and a set of timestamps. Tools like ls, file, and stat each expose a different slice of it.

They also answer different questions, and it matters more than it sounds. ls -ld describes the named entry rather than listing what’s inside it, stat reports the filesystem metadata, and file looks at the available metadata and will usually sniff the content patterns of a regular file in order to make a guess at its classification. None of them can tell you a program is safe or a document is honest. “What kind of object is this?” is a much narrower question than “should I trust it?”. These tools only answer the first one.

Return to the course practice area and create a disposable set of files:

cd ~/underdunn-course/exercises
rm -rf file-identity-practice
mkdir file-identity-practice
cd file-identity-practice
mkdir report.pdf
touch notes.jpg
ln -s notes.jpg latest
touch runner
chmod u+x runner

That first line is a reset, and it’s worth understanding before you run it. rm deletes, -r makes it recurse into a directory and everything inside it, and -f tells it not to complain about a missing directory. Recursive forced deletion is powerful and completely unforgiving, and it will not ask you for confirmation or quietly move anything into a trash can on the way past. So the safety rule is short. Confirm your location with pwd first, and then only ever name one specific disposable directory (never a variable, and never a path you have just typed in from memory). Never aim rm -rf at your home directory, at /, or at any path you are not certain about. Here it removes only file-identity-practice inside the course practice area, so rerunning the setup always starts from a clean tree.

Predict from names, then inspect

Before you run anything else, predict the type of each of these four names: report.pdf, notes.jpg, latest, and runner.

Now inspect the entries themselves, rather than what’s inside the directory:

ls -ld report.pdf notes.jpg latest runner
file report.pdf notes.jpg latest runner

Expected identifying evidence includes:

report.pdf: directory
notes.jpg:  empty
latest:     symbolic link to notes.jpg
runner:     empty

Your spacing may well differ from mine. The first character of each long-listing mode is evidence too, where d starts a directory entry, l starts a symbolic link, and - starts a regular file.

The x in runner’s owner permissions records only the owner’s permission to request execution, and it says nothing at all about whether the empty file holds a valid program.

The latest entry shows off another distinction worth having. A symbolic link is a small filesystem object whose contents happen to be the name of another path somewhere else on the system. Depending on the options you pass, a tool will either describe the link itself or follow it and describe the target instead. When the difference matters, say which of the two objects you actually inspected. Check the link’s path and its target so another reader can tell which object you examined.

Inspect one complete metadata record

Run:

stat notes.jpg

Now go and find these fields in your own output:

Field	What it reports
`File`	The name inspected.
`Size`	The file’s current byte count.
File type or mode prefix	The kind of filesystem object.
`Access`	Mode bits in numeric and symbolic form.
`Uid` / `Gid`	Owner and group identities.
Timestamps	Recorded access, modification, and metadata-change times.

Check which timestamp field answers your question, along with the value you observed. The meaning of the field matters more than memorizing the example’s date.

Those timestamps describe genuinely different events, and mixing them up causes a lot of bad conclusions:

Modification time moves when the file’s contents change.
Change time moves for a content change too, and also for metadata like mode or ownership.
Access time moves on reads.

Access time is the one to be careful with, because Linux often updates it lazily for performance (a missing update is much weaker evidence than it looks). A timestamp is evidence that the filesystem recorded an event, and that’s all it is. It is not a record of who did the thing, and it is certainly not a record of why.

The stat manual identifies the device, inode, and link-count fields. Use those fields together when two names may refer to one file.

Change one property

Predict which part of stat runner is going to change after this command, and write it down:

chmod u-x runner

Compare:

stat runner
ls -l runner

The size stays at zero, and the owner execute bit disappears from both outputs. So one metadata property changed, and the contents did not change at all. The conclusion: permissions are metadata, kept separately from whatever the file holds.

Put the setup state back with chmod u+x runner before you move on.

Practice: classify before opening

For each of the four names, compare the type you expected with ls -ld and file. For latest, inspect the link target as well. Don’t use cat to classify any of these. The whole point is deciding what something is before you open it.

Common failures and recovery

ln: failed to create symbolic link: check you’re inside file-identity-practice, and check latest doesn’t already exist. The reset block rebuilds the tree cleanly.
file latest reports the target instead of the link: treat ls -ld latest as the authoritative observation, and compare the disagreement (versions really do differ here).
Permission denied when you try to run runner: that’s the expected result. An execute bit doesn’t turn an empty file into a working program.
The tree no longer matches: check pwd, remove only ~/underdunn-course/exercises/file-identity-practice, and run the setup block again. I’d read that path twice before pressing Enter.

Check your result

report.pdf should be a directory, notes.jpg an empty file, latest a symbolic link, and runner a script. Check the tool output rather than trusting the extensions. If latest is confusing, use ls -ld and readlink to distinguish the link from its target. Keep the directory for the next lab.