|
From: Anton A. <ai...@ca...> - 2003-09-24 13:38:38
|
Hi,
On Tue, 2003-09-23 at 19:28, Richard Russon wrote:
> First off, CONGRATULATIONS! We wondered when you'd tell your "extended
> family". Please pass on my best wishes to Collette and smiles and
> gurgles to Hattie :-)
Thanks! Will do.
> > I noticed your changeset in ntfsprogs/utils.c which describes a bug in
> > ntfs_attr_lookup().
>
> Yes. Whilst tweaking ntfscluster I found that ntfs_attr_lookup managed
> to get me in an infinite loop. For now, I've put a check in the utils
> code[1], but the problem is the reinit search ctx[2]. Removing that
> line fixes my problem, but I can't (have had no time to) prove that it
> doesn't break something else.
>
> [1] utils.c utils_inode_get_name
>
> while ((rec = find_attribute (AT_FILE_NAME, ctx))) {
> if (rec == oldrec)
> break; // infinite loop!
> oldrec = rec;
>
> [2] attrib.c ntfs_external_attr_find
>
> not_found:
> /*
> * Seek to the end of the base mft record, i.e. when we return false,
> * ctx->mrec and ctx->attr indicate where the attribute should be
> * inserted into the attribute record.
> * And of course ctx->al_entry points to the end of the attribute
> * list inside ctx->base_ntfs_ino->attr_list.
> *
> * FIXME: Do we really want to do this here? Think about it... (AIA)
> */
> ntfs_attr_reinit_search_ctx(ctx);
>
> I'm still hoping to enumerate all the different patterns of attributes
> in FILE records that could occur, all the methods of searching (as I did
> for the attr merging), so I could build a test rig.
That would be great.
> > Do you have an example mft record where this
> > happens? If yes, can I have a copy?
>
> The bug occurs if you have two FILE records, an attribute list, and an
> attribute which only occurs in the first record (not 0x20). Search for
> this record and ntfs_attr_lookup keeps returning it, and keeps returning
> zero.
Right! I understand. Especially after reading the relevant part of the
code I can see how it happens.
> I've got a couple of vmware disks that can trigger the problem, but
> they're a gig a piece. I'll see what I can do to cut out the bits you
> want.
Thanks, no longer necessary. Your excellent description was sufficient
for me to understand it and I think I have just committed a fix for
this. It is both in ntfsprogs and ntfsprogs-devel. I also removed your
workaround form utils.c so could you test the current code and let me
know whether it is really fixed or whether it hangs again? Thanks a lot
in advance!
> As I'm the only one using ntfs_attr_lookup in this manner and the only
> one using utils_inode_get_name, there's no problem if you want to
> release a new ntfsprogs.
I will wait till I know it is fixed especially as I believe it _is_ now
fixed. (-:
While on this subject, everyone please test the current ntfsprogs
utilities as this is going to be released very soon as 1.7.2beta and a
few weeks later as 1.7.2.
Also ntfsprogs-devel is going to be released as 1.8.0beta soon
thereafter and as 1.8.0 a few weeks after that. I want to see all the
man pages finished before this happens though.
Rich, I noticed you have done lots of work on the man pages so we don't
have a single empty one any more. Could you let me know which ones
still need work / which ones are finished / which ones you are going to
finish so I know where to pick to do some work (time allowing), too.
Cheers,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ &
http://www-stu.christs.cam.ac.uk/~aia21/
|
