Chris's Wiki :: blog/unix/DirectoryDTypeHistory Commentshttps://utcc.utoronto.ca/~cks/space/blog/unix/DirectoryDTypeHistory?atomcommentsDWiki2019-05-29T18:36:55ZRecent comments in Chris's Wiki :: blog/unix/DirectoryDTypeHistory.By William Jolitz on /blog/unix/DirectoryDTypeHistorytag:CSpace:blog/unix/DirectoryDTypeHistory:530f73c663b9ff6b0e71f7d59084be4e005c19a7William Jolitzhttps://github.com/williamjolitz<div class="wikitext"><p>The rational behind keeping metadata out of directories was to have it all in one to allow for referential integrity, i.e. if it was in the directory and the statb/inode, then one might have a disagreement between the two.</p>
<p>UNIX was austere in directory information to prevent too much of the underlying filesystem information/abstraction "leaking" into the application's field of view. Following MULTICS likewise.</p>
<p>As it is, this created problems for labelled security (B1) implementations with the dependencies on parent/current directories ('.', '.."), making ACL's function sensibly, as well as omitting directory entries (link count) when security level did not allow files to be present in the directory - effectively the contents of the directory were rewritten on the fly. Ran into this at HP on their government labelled secure HP-UX implementation.</p>
<p>With non UNIX systems that have considerable attributes, trying to represent the applications view with the underlying filesystems one is an even more extensive rewrite.</p>
<p>So the point of the controversial addition of d_type (I disagreed with, thus why it didn't show up in 386BSD, because when at Sun Microsystems I'd had this debate) was to do "hinting" so that filesystem walk functions like fts() would have an advantage. Since BSD was usually well documented, one reason to leave it less so might be to allow the hint to be present but not used. Also, in such cases it was also to allow a follow-on (not to happen as BSD was "wound down" after 4.4 wisely) for potentially like hinting of a related but unresolved kind. So think of this as opaque inside of the structure, almost like field alignment.</p>
<p>My suggestion is that an opaque field in the dirent is what was desired long term.</p>
<p>Came across this as I was going though my 386BSD archives and putting them into github, including a request I'd gotten to allow interoperability with 4.4 UFS.</p>
<p>Believe Illuminos doesn't have it because SUNOS/Solaris didn't, because PSARC wanted it that way.</p>
</div>2019-05-29T18:36:55ZBy Late on /blog/unix/DirectoryDTypeHistorytag:CSpace:blog/unix/DirectoryDTypeHistory:35a02831b0526816b57bf3ccdf8de648f7583217Late<div class="wikitext"><p>If you are interested also in QNX:</p>
<p><a href="http://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx.doc.neutrino.lib_ref/topic/r/readdir.html">http://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx.doc.neutrino.lib_ref/topic/r/readdir.html</a></p>
<p>So one needs to use special ugly-looking macros to get extra info out of struct dirent.</p>
</div>2018-12-21T11:37:47ZFrom 78.58.206.110 on /blog/unix/DirectoryDTypeHistorytag:CSpace:blog/unix/DirectoryDTypeHistory:e926350765f4f46353eb9e54a6469ab168e1ebc8From 78.58.206.110<div class="wikitext"><p>A better source of historical Linux commits is: <a href="https://archive.org/download/git-history-of-linux">https://archive.org/download/git-history-of-linux</a></p>
<p>(alternatively: <a href="https://github.com/remram44/linux-full-history">https://github.com/remram44/linux-full-history</a>)</p>
<p>This includes all the repositories you've found, combined into one continuous chain -- so that you can <code>git grep</code> all the way to Linux 0.01.</p>
<p>A similar project for various BSDs is: <a href="https://github.com/dspinellis/unix-history-repo">https://github.com/dspinellis/unix-history-repo</a></p>
</div>2018-08-25T11:32:55Z