> This was the change that came up on the thread "fatfs locking". It might > still be desireable for fatfs, but I don't know enough about that case to > really be sure.
There is no fix for the fatfs locking problem yet. This patch can fix the problem :). I thought about an other solution for the problem, although it is a stange solution it might solve the problem. The thread in fatfs will deadlock because that thread already locked the node, what if the function that locks the node check if the node is locked by that thread and won't lock if it is? That will solve the problem and won't cause troubles for other diskfs translators. I was thinking about the functions "diskfs_lock_node" and "diskfs_unlock_node". If everybody agrees I'm willing to write those and adept libdiskfs and the translators using libdiskfs to use those functions. Another solution is not locking the directory but locking the directory entries instead. Personally I don't like this solution because it doesn't use libdiskfs' locking mechanisms. I haven't tried this solution yet, it can be hard to implement and it make fatfs slow (a lot over overhead, locking every entry makes diskfs_get_directs slow I think). I'm not 100% sure if this is possible. Reading in fatfs already works, writing is almost working. This is one of the last problems that needs to be solved :) Thanks, Marco Gerards _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
