|
From: Anton A. <ai...@ca...> - 2004-03-12 16:34:03
|
Hi all, I have modified the meaning of volume->nr_mft_records as follows: "Modify meaning of ntfs_volume->nr_mft_records to be the number of initialized mft records, not total mft records. This makes far more sense and in fact reflects how nr_mft_records is being used in both libntfs and the utilities." Further, modified is that you can only read/write mft records up to nr_mft_records. Trying to access beyond that gives you an error with errno set to ESPIPE (it used to be ENOTSUP on write, ESPIPE on read). Rationale for both these changes: If the mft record isn't initialized, it cannot possibly be allocated or deleted or anything else, it will just be full of zeroes on read so it would be completely useless. If you wanted to be able to read or write a valid mft record there, you would have called ntfs_mft_record_alloc() first, which would extend the initialized size (as well as the data size, the allocated size, and it would perform the appropriate allocations and bitmap updates of course) and then wrote the mft record which would work fine as nr_mft_records would now be extended to cover your allocated mft record. [Slight catch here is that ntfs_mft_record_alloc() isn't actually implemented yet but that's a minor detail... (-;] Could people using nr_mft_records in their applications double check for me and tell me if this is a problem for them? I looked in ntfsprogs and I believe that this is what most if not all of the utilities actually wanted... Best regards, 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/ |
