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 [EMAIL PROTECTED] > Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] > [EMAIL PROTECTED] > http://www.marcus-brinkmann.de -- from da Bobstopper (Public Key available at http://bobturf.australispro.com.au/publickey.html) _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
