|
From: Anton A. <ai...@ca...> - 2004-05-12 22:09:04
|
Hi Rich, On Tue, 11 May 2004, Richard Russon wrote: > What state is the code to manipulate MFT records? I'd like to be able > to add a record, e.g. INDEX_ALLOC, change the size of a record, e.g. > INDEX_ROOT and be able to ask how much space is free (in the record). In kernel none of this is possible at present. In libntfs you can't yet add/remove records but that should be almost trivial (for the non-attribute list attribute present/necessary case). You can resize resident attributes both making them smaller and bigger and converting them to non-resident attributes if they support it. So you should be able to resize INDEX_ROOT without problems already. You just need to trerat EOPNOTSUP the same wasy ENOSPC. See libntfs/attrib.c::ntfs_resident_attr_resize(). For adding an attribute you would need to: Determine the amount of space needed by the new attribute. get search context ctx. ntfs_attr_lookup(...,ctx) for the attribute you want to insert and get errno == ENOENT. Then using the same ctx use a not yet existant function to create space in the mft record (see ntfsprogs/mkntfs.c::make_room_for_attribute()). If this returns ENOSPC then you know we can't do it. (In the future you will never get this unless you are asking for a too large chunk of resident attribute space (i.e. larger than an mft record) as we will be able to use extent records.) Then create the new attribute in the created space. and make it point properly at the next attribute. (See ntfsprogs/mkntfs.c::add_attr_index_alloc() and attr_attr_index_root() for examples and the functions they call.) Done. (-; Admittedly still a lot of work needed in the library to get all these functions in there but the end is in sight... > > > Great. These should be summarized on the web also somehow IMHO. > > We need more than that, much more. IMHO, the news needs to be less > formal, and needs tell people how we're getting on. At the moment we > have quite a lots of page hits, but I doubt anyone comes back! Probably true but who wants to write news items? > > Something about what, and how, people could help. > > We keep scaring people off. Beginners don't want to do the boring tasks > and they can't manage the sexy stuff. > > > Not necessarily kernel coding but also updating, cleaning > > documentation, web pages, testing, etc. > > Yes, great. And I think that replacing the help forums with a wiki > would be a step forward. Get a community rather than a few individuals. > But... who's going to _manage_ all that. It won't just happen on its > own. Yes wiki would probably be fantastic. But as you say all these things require people to do them and all of them would take away from our already scarce time for development... > [sigh] > > tools are useful, but people want write support > we have the skills to deliver write support > it's almost impossible to deliver write support in a piecemeal fashion > ntfsprogs / website distract us from development > > suggestions? (in no particular order) > > stop ntfsprogs devel No, we need that for testing/development I think. A lot easier than kernel even when using VMware or UML... > campaign for money (to work full time) But that takes a lot of time and effort in itself... > close the mailing lists Need them for bug reports and developer discussions... > give priority to driver Definitely. > a big PR campaign > recruitment drive > campaign for developers (to spread the load) All require a lot of time. )-: > give up No way! (-: We have come this far... > close the website Better to just say "This web site is no longer being updated due to lack of resources. If you want to help keep it uptodate please email us." at the top rather than shut it. You never know might get a few volunteers... (-; > give priority to ntfsprogs No, kernel is more important... At least to me... But utilities like ntfsresize, mkntfs, and ntfsclone are very useful for users and distros and to bring Linux to the masses of Windows users so we shouldn't just abandon them altogether... One added item: stop offering help to people; only answer bug reports and ignore everything else. Would save a _lot_ of time... (-; Cheers, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
