|
From: Anton A. <ai...@cu...> - 2001-04-03 00:00:03
|
As of today the CVS finally compiles again and as far as I can tell, it works fine, too. At least my partitions survived the testing of ntfsfix. There still is no attribute list support. But searching for attributes has become a lot cleaner (IMHO) and uses a search context so you can easily iterate over all/several attibutes. - Due to lack of attribute list support spurious error messages are being generated when an attribute list is encountered. - Not intending to fix the error messages as I want to get attribute list support working, instead. (-8 Currently include/attrib_RE.h and libntfs/attrib_RE.c contain what the driver does to search for attributes while taking care of existing attribute lists. It's ugly and very complex but if you are interested have a look. I want to do it differently while preserving the essential collation rules (which is why I bothered RE-ing what the driver does in the first place). Perhaps to have one function for searching an attribute list, just like find_attr() (find_attr() searches an mft record ignoring an attribute list). The new function would work the same way, except it would search the attribute list instead of the mft record, and if none is present, it would call find_attr(). If an attribute list is present, it would be searched, and if the found attribute is part of the base mft record, find_attr() would be called. If the attribute is in an extension mft record, the mft record will be read, and find_attr() will be called on it. This sounds nice and easy until we consider how to implement the search context. Problems are for example: Assume we have called the new function once, which resulted in an extensin mft record being read and an attribute being returned. First problem: what happens with the old (base) mft record stored in the search context? It needs to be preserved somehow, as does the attribute list attribute pointer to the found attribute, otherwise we don't know where to continue the search the next time the function is called. Also, on second call, the function needs to be able to tell that we stopped inside an attribute list and continue from there. Now the function is called a second time. Second problem: what do we do with the old extension mft record? We don't want to leak memory so we can't just drop it. On the other hand, we don't know whether the user doesn't still hold references to the attribute within the mft record, so we can't just free() it. It would seem we need a linked list of all loaded mft records perhaps? Or just policy?, e.g. when calling the function you need to have finished with the found attribute and hold no references to it any more? Eventually these problems will go away to a big part as we will just be locking/unlocking the mft records which will be present in the page cache (or at least so for the future ntfs driver), but we need a simple, managable solution for user space now. If anyone has any ideas/suggestions/comments on this I sure would like to hear them - or rather as it would be, read them. (-; Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Linux NTFS maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ |
