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

On Sun, 23 Jul 2006 at 22:49 +0100, Anton Altaparmakov wrote:
> 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...

It caused ENOENT errno from ntfs_delete, because ntfs_delete was unable
to find requested FILE_NAME attribute during enumeration (see algorithm
if you interested in details, I think it pretty well commented).

> /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!

Thanks for the fix!

-- 
Best regards,
        Yura


-------------------------------------------------------------------------
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