|
From: Anton A. <ai...@ca...> - 2006-07-27 19:00:27
|
On Thu, 27 Jul 2006, Yura Pakhuchiy wrote: > On Thu, 27 Jul 2006 at 09:52 +0100, Anton Altaparmakov wrote: > > Argh. You do evil things! (-; It now works again but please note that > > I believe what you do still is have a bug and will randomly cause > > corruption of the attribute list attribute because the attribute list > > entries will be sorted incorrectly. Basically if SFU was a file rather > > than a directory and you instead of renaming it added hard links to it > > you would find that at least some of the hard links are incorrectly > > ordered in the attribute list attribute. (It would be a complete per > > chance event as to which will go where.) This is arguably a bug in > > ntfs_external_attr_find() or it could be argued to be a bug of > > ntfs_attrlist_entry_add(). > > Why attributes list can be sorted incorrectly? AFAIR you suggested me to > rewrite ntfs_attrlist_entry_add using ntfs_attr_lookup to find correct > place for new entry. ntfs_attr_lookup does not guarantee that attribute > list entry will be placed to the correct place anymore? Yes, I think the function does not do the right thing in all cases as it is at the moment. It only does things 100% correct for the non-attribute list attribute case. > > Also I think you have a potential bug in that you add the attribute to > > the mft record before you have added it to the attribute list attribute > > and then you call ntfs_attr_lookup() on what effectively is a corrupt > > inode. The only reason this works is a complete pure chance/luck and > > stronger sanity checking would make this code break... > > I think that the best solution will be to return to old algorithm in the > ntfs_attrlist_entry_add (that does not use ntfs_attr_lookup). Attribute Perhaps. Or perhaps best solution is to fix ntfs_attr_lookup()... > list will be sorted by: > 1. Number > 2. Name > 3. Instance number (for resident attributes) and lowest VCN (for > non-resident attributes) > This is correct algorithm? No, it cannot be sufficient. For example you have two file names, one in the base mft record X and one in an extent mft record Y. And both of those have independent instance numbers and say they are both equal to N. So in the attribute list attribute you then have two identical entries with the same instance numbers and the only difference (AFAICS) is the mft record number to which they belong. Currently ntfs_attr_lookup() will place any new ones after any existing ones (hence ordering is in fact random). I imagine that Windows has a specific ordering requirement and thus we will get it wrong some of the time. I am afraid this is such a corner case that I do not actually know the answer as to what is the correct ordering. We will somehow need to experiment. Perhaps by creating a file in Windows and making it have a really long file name and then creating lots and lots of hard links with really long names to it. Then it will eventually end up in the situation when there will be lots of file names in each mft record and there will be lots of extent mft records. And then look at the ordering in the attribute list attribute to see what Windows does. And one better - reverse (using a hexeditor) the order of two of them by swapping the mft record references to two adjacent entries with the same instance number and then running chkdsk to see if it complains. If it does complain then the order is important and this ordering needs to be added into ntfs_external_attr_find() and if it is not important then ntfs_attr_lookup() is fine and will always generate the correct result (I think - it may still get the sequence numbers wrong, need to double check)... 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, http://www.linux-ntfs.org/ |
