|
From: Yura P. <pak...@gm...> - 2006-07-28 21:14:57
|
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?
> 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
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?
--
Best regards,
Yura
|
