Re: MS-DOS translator and ACLs

[Robert Marlow]

Great, thanks for all the info - it should be very helpful in getting me
started. I'll make my attempt at it ASAP. I'll certainly be taking up your
offer for help since I'm not hugely experienced with C programming (which
is the main reason I want to find something like this to do).

Thanks, Marcus


On Thu, Jan 03, 2002 at 06:20:33PM +0100, Marcus Brinkmann wrote:
> On Thu, Jan 03, 2002 at 07:39:42PM +0800, Robert Marlow wrote:
> > Hi people. I was wondering if anyone was working on a translator for 
> > MS-DOS filesystems. If not or if they need help I'd like to take a 
> > swing at it. What's involved?
> 
> The link Neal posted has a snapshot of the last version I touched.  It has
> partial and broken write support.  reading worked fine for me.
> 
> The issue was that fat has no inodes, so write support is difficult.  You
> have to modify the directory entry if you update the inode information
> (time stamps!, renaming of files etc), so what you need to do is to get a
> lock of the node _and_ a lock of the directory the node is in before you can
> do that.
> 
> It turns out that the filesystem-with-inode case is simpler to program for,
> and libdiskfs assumes that inodes are seperate from directories in several
> places.  So there are two things that need to be done to make it work at
> all:
> 
> * Maybe fix the interface to libdiskfs to make inodeless filesystems
> possible  (i forgot the details, but one callback was called in the
> directory-is-locked case and in the directory-is-not-locked case without
> telling which case it is, so you could not find out if you still have to
> lock the dir or not -> deadlock risk)
> * override those parts of libdiskfs which don't work on inodeless file systems
> * override those parts of libdiskfs which don't work on file systems without
> hard link support (there are some operations in libdiskfs assuming that hard
> links work).
> 
> And then to make it functional:
> * add the lacking callbacks.  What is there should be enough for extending
> files.  what is missing (IIRC) is creating files, renaming, deleting etc etc
> * from there, add some gimmicks like code maps, long file name support,
> making use of the extra superblock containing a current count of the free
> blocks (for faster df) etc
> 
> So, there is a lot to do.   Back then when I stopped working on it I didn't
> have the time (and probably the knowledge) to know how to fix the lock
> contention stuff.  That's why I gave up on it and pursued other stuff.  As
> of today I forgot most details, so it takes about as much as time for me to
> pick it up again as for everyone else.  In other words: Have a go! :)
> I am happy to assist in every question you might have, and might turn my
> attention to the code one more time if you have some patches etc.
> 
> fatfs is not unimportant, and if the code works, it will surely make its way
> into the Hurd main tree.  It's on the todo list, btw.
> 
> Thanks,
> Marcus
> 
> -- 
> `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
> Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
> Marcus.Brinkmann@ruhr-uni-bochum.de
> http://www.marcus-brinkmann.de

-- 
from

da Bobstopper
(Public Key available at http://bobturf.australispro.com.au/publickey.html)