|
From: Anton A. <ai...@cu...> - 2001-03-26 14:21:45
|
On Mon, 26 Mar 2001, Michael N. Filippov wrote: > 1. I have a lot of questions and several answers (i hope) and not sure > which mailing list is more populated. I see that almost every active > member is registered here (http://tiger.informatik.hu-berlin.de/cgi-bin/mailman/listinfo/linux-ntfs) > and on sourceforge (http://sourceforge.net/projects/linux-ntfs) and have > to send copy. Why not to merge them. All - go to sourceforge :) ! (for > example.). It would be fine i think. At the moment, there are only 13 email addresses registered on the Sourceforge list, so if you want to reach lots of people you are better off sending your message to @tiger address. I don't mind merging them but I am not sure everyone on @tiger is interested in the content of @sourceforge, i.e. development of linux-ntfs project (which at the moment is admittedly close to zero, but that might change in the future...). What do other people think? > 2. I installed Windows Whistler Server (XP) to look at > NTFS 3.1 (as written in its $Volume file). The first change i see is > that in file record record_header->update_sequence_header.offset is 0x30 > instead of typical 0x2A. These 6 bytes for every file/directory on > disk (i copied one directory without system/hidden etc files) have such > layout: first 4 bytes - mft_index, 2 bytes - zero. It means that only 32 > bits are reserved instead of 48. Any guesses ? When you say mft_index, do you mean that this is the index number of the mft record in which mft_index is stored? (quite a bizzarre thing to store as it is completely redundant, but it does make sense for recovery purposes). Could you just confirm I understood you correctly? If you have a kernel debugger why not check out how it is accessed? I don't have any version of XP but my guess would be that it still is 48-bits for the index. Don't forget it is stored in little endian, so that the first byte is the least significant byte. So effectively, the first four bytes are the lower 32-bits of the mft record number. The next two bytes, which you note as zero, are the high 16-bits of the mft record number (zero for you as your volume doesn't have 4Gi of files on it) and the final two bytes are of course the sequence_number which is also present in the mft_record at offset 0x10. Could you confirm that the two sequence numbers match up? If they do, and I understood you correctly above, we now have full specs on at least one of the new features in NTFS 3.1. (-: 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/ |
