Re: [announcement] ntfs-3g: open source read-write driver

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/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV