|
From: Anton A. <ai...@ca...> - 2006-07-23 21:49:53
|
On Sun, 23 Jul 2006, Yura Pakhuchiy wrote: > On Sun, 23 Jul 2006 at 08:33 +0300, Yura Pakhuchiy wrote: > > On Sat, 15 Jul 2006 at 20:46 +0100, Anton Altaparmakov wrote: > > > > > > Problem: "No such file or directory" message when accessing some files: > > > > > > Answer: This is a known problem in libntfs inode attribute enumeration > > > > > > when the same type of attributes are distributed across > > > > > > multiply mft records. Occures only very rarely. > > > > > > Workaround: If the file is a hard link (usually yes) then first delete > > > > > > some other files hard linking to the same file then you'll > > > > > > be able to delete the problematic file as well. > > > > > > Status: High priority work. > > > > > > > > > > Interesting. This is the first time I hear of this problem. Why did you > > > > > not report it? Do you have an example where this happens? > > > > > > > > I identified this problem before yesterday. Sometimes I can reproduce it by > > > > > > > > cp -a /usr ntfs_volume > > > > rm -rf ntfs_volume/usr > > > > > > > > Most ntfs volumes have also such cases usually, so if you rm -rf / then you > > > > can find them easily. > > > > > > Weird. I wonder if it is something libntfs specific and not in the > > > kernel as I have never seen this problem... > > > > This is kernel driver problem too. It seems our knowledge about > > attribute list a bit incorrect. ntfs_external_attr_find written in mind > > with that attributes in the MFT record follow in same order as they > > follow in attribute list. Metadata (link to which I send in previous > > email) demonstrates vice-versa. FILE_NAME attributes follow in order 2, > > 3 (instance numbers) in the attribute list, but 3, 2 in the MFT record. You are correct that instance numbers are in sequence in attribute list attribute and are not in order in the mft record. This is because the sequence numbers are used for collation in the attribute list attribute and they are not used for collation in the mft record (instead the attribute value is used which in case of the file name attribute means that the sequence number is irrelevant and the name is relevant instead). What I don't understand is how that is causing file not found problems... /me reads through ntfs_external_attr_find(). /me sees stupendously stupid bug and bashes head against wall repeatedly. /me fixes bug and commits it to ntfsprogs. I cannot believe this has not been found earlier! This bug has been there since I originally wrote ntfs_external_attr_find() which was quite a few years ago now! Amazing! Yura and Szaka, thanks a lot for pointing out the problem and providing an example so I could fix it! 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/ |
