bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MS-DOS translator and ACLs


From: Marcus Brinkmann
Subject: Re: MS-DOS translator and ACLs
Date: Thu, 3 Jan 2002 18:20:33 +0100
User-agent: Mutt/1.3.24i

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]