<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 26 June 2016 at 21:50, Thomas Levine <span dir="ltr"><<a href="mailto:_@thomaslevine.com" target="_blank">_@thomaslevine.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The directory of course contains references to its children, but that's<br>
not the information I'm thinking about accessing; I naively think that a<br>
directory should be able to contain both a list of children (that I can<br>
display with ls) and an arbitrary blob of unrelated data (that I can<br>
display with cat); why I have never seen a system that works like this?<br></blockquote><div><br><br></div><div>In early unicies (UNIX Version 7 for example) there was only a single file system with a fairly simple struct interface. As such, read() and write() worked exactly as they do on regular files. There was no readdir(), opendir() specific system calls.<br></div><div>Some unicies have retained bits of this, for example the ability to read() a directory. It would be directly against the history for these unicies to work as you describe. For systems that started more recently, I suspect they did not want to invent new semantics where they could be easily confused.<br><br></div><div>There are some elements of what you describe as 'extended attributes' (typically stored in the directory inode) or 'resource forks' (typically stored as additional, alternate data blocks).<br></div></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Eitan Adler</div>
</div></div>