# cksum



## KBK (Mar 26, 2021)

Hello there

A beginners question: I noticed that cksum(1) 
create a checksum also of the directories. 
I am just curious, is this an expected behavior?
Conform to IEEE Std 1003.2 1992 (POSIX.2)?

Also md5, sha1, sha256, sha384, sha512, sha512t256 behave like that
in FreeBSD but not in OpenBSD or Linux.

OS version is FreeBSD 11.4-RELEASE-p8

Thanks


----------



## zirias@ (Mar 26, 2021)

KBK said:


> A beginners question: I noticed that cksum(1)
> create a checksum also of the directories.


It doesn't here on 13.0-RC3:

```
$ cksum /tmp
cksum: /tmp: Is a directory
```



KBK said:


> I am just curious, is this an expected behavior?
> Conform to IEEE Std 1003.2 1992 (POSIX.2)?


I can't find anything in POSIX specs that would _forbid_ it to work on directories, as they are just "special files". But whether this is in practice a "bug" or a "pretty useless feature", I'm unsure about  (useless because AFAIK the "content" of a directory when read as a file is implementation-defined)


----------



## ShelLuser (Mar 26, 2021)

If you want a full checksum of a directory structure you should look into mtree(8), I even wrote a guide about that some time ago.


----------



## PMc (Mar 26, 2021)

I remember there was some release notes: one might run into errors because read attempts on directories would be blocked from now on. Not certain, this might have been introduced with R.12


----------



## ralphbsz (Mar 26, 2021)

Traditionally, directories were readable using open() and read(), as if they were a regular file. The content one found there was a list of directory structures, see "struct dirent" in some system header files. The problem with this approach was that the binary layout of the structures was OS- and file system dependent, which made code that actually used the data read from directories really messy. So about 30 years ago, someone (don't remember whether it was Bell Labs, Berkeley or SysV) added the opendir() and readdir() functions, which simplified and standardized this. At this point, there was no longer an immediate need to read directories as if they were files.

Over the next few decades, various Unixes then disallowed reading directories directly with read(). If I remember right, Linux file systems prohibited it very early, because in the early 90s, Linux didn't have the baggage of lots of old software that had to be kept compatible. Interestingly, the *BSDs allowed reading directories for a very long time. And that's why cksum works: it can just read the directory. You can also use cat on them. The interesting one is "hexdump -C", which shows you the data structures. Recently, FreeBSD has turned this off. I don't remember exactly when, but the fact that you are running 11.4 and can still do it, and my home machine is running 12.2 can can no longer do it pretty much tells us when.


----------



## zirias@ (Mar 26, 2021)

ralphbsz said:


> At this point, there was no longer an immediate need to read directories as if they were files.


Still they arguably _are_ files  But thanks for the elaborate explanation!


----------



## ralphbsz (Mar 26, 2021)

Whether soft links, device nodes, FIFOs or directories really "are" files is a philosophical question. Or a theological one. In the same category as "how many angels can dance on the head of a pin". For which there is a really good answer: One, but only if the dance is the gavotte. If you want proof, search the web for "good omens aziraphale dance pin" or some combination.

What is clear: Reading from those things that are file system objects but not files does not give the same result as reading from a real file. In some cases, it makes no sense at all.


----------



## KBK (Mar 27, 2021)

Thanks all
and a special thank to ShelLusser that point me to mtree and to ralphbsz that wrote about the history and the rationale of this old cksum behave.
Really informative.

KBK


----------

