Comments on: Old, old bug http://www.shiningsilence.com/dbsdlog/2008/05/09/2825.html A running description of activity related to DragonFly BSD. Mon, 01 Dec 2008 21:08:11 +0000 http://wordpress.org/?v=2.6.3 By: Lazarus http://www.shiningsilence.com/dbsdlog/2008/05/09/2825.html#comment-23694 Lazarus Sat, 10 May 2008 22:29:12 +0000 http://www.shiningsilence.com/dbsdlog/?p=2825#comment-23694 "<I>Marc and worked out the issues and I am going to commit his fix, because it can't hurt, but unfortunately there is a DragonFly-specific issue due to our modern readdir which translate directory entries into a filesystem-independant form. And, stupid me, when I created the dirent structure I didn't add enough reserved fields to hold what we need, which is a full blown cookie for each entry. We only have 40 bits worth of unused fields and we need 64 bits. <B>I don't dare change that structure now, it would require every single application ever written to be recompiled.</B> It may be possible to store a filename hash in the unused fields and then match up against the hash instead of the buffer position. The problem with that though is that it would not be perfect or even close to perfect."</I> Anyone else think that said structure should just be increased to 64 bits from 40 so we can all be done with it? In a follow-up email it was suggested that this be done for DragonFly 2.0 despite the changes requiring a complete rebuild of third party programs. It seems to me to be the best way to go about things as DragonFly is in a good place right now; there's plenty of people interested in it, but there is not such a massive installed base in existence requiring the developers to worry *too* much about not breaking things for the sake of backwards compatibility. I understand that my opinion matters little in a project I'm not actively involved in, but for what it's worth, that'd be my vote. Fix it for 2.0 and rebuild apps as needed. “Marc and worked out the issues and I am going to commit his fix, because
it can’t hurt, but unfortunately there is a DragonFly-specific issue
due to our modern readdir which translate directory entries into
a filesystem-independant form.

And, stupid me, when I created the dirent structure I didn’t add enough
reserved fields to hold what we need, which is a full blown cookie for
each entry. We only have 40 bits worth of unused fields and we need
64 bits. I don’t dare change that structure now, it would require
every single application ever written to be recompiled.

It may be possible to store a filename hash in the unused fields and
then match up against the hash instead of the buffer position. The
problem with that though is that it would not be perfect or even close
to perfect.”

Anyone else think that said structure should just be increased to 64 bits from 40 so we can all be done with it? In a follow-up email it was suggested that this be done for DragonFly 2.0 despite the changes requiring a complete rebuild of third party programs.

It seems to me to be the best way to go about things as DragonFly is in a good place right now; there’s plenty of people interested in it, but there is not such a massive installed base in existence requiring the developers to worry *too* much about not breaking things for the sake of backwards compatibility.

I understand that my opinion matters little in a project I’m not actively involved in, but for what it’s worth, that’d be my vote. Fix it for 2.0 and rebuild apps as needed.

]]>