On Wed, 2005-08-24 at 15:50 +0100, Anton Altaparmakov wrote:
> On Wed, 24 Aug 2005, Yura Pakhuchiy wrote:
> > On Tue, 2005-08-23 at 15:01 +0100, Anton Altaparmakov wrote:
> > > On Tue, 2005-08-23 at 16:33 +0300, Yura Pakhuchiy wrote:
> > > > AFAICS FILE_NAME attribute is always unnamed, so it's possible for one
> > > > inode to have several unnamed FILE_NAME attributes, but there is no way
> > > > to tell ntfs_attr_open which of them to use. Or I'm missing something?
> > > >
> > > > BTW, really don't know how such attributes collated. In attachment
> > >
> > > Very easy. Not. Read libntfs/attrib.c::ntfs_attr_lookup() and its two
> > > helper functions. They implement it correctly based on months of
> > > reverse engineering ntfs.sys.
> > >
> > > I am very busy at work atm so can't explain. If you can't figure it out
> > > let me know and I will try to explain this weekend.
> >
> > Maybe I explained question bad, but ntfs_attr_lookup has no answer on my
> > question, AFAICS it returns such attributes (resident, with same type
> > and name) in order of their appearance.
>
> We must be talking past each other. )-:
>
> Please read the function description above ntfs_attr_lookup() and pay
> particular attention to the @val and @val_len arguments.
>
> If this still does not answer your question perhaps you can explain what
> exactly you want to do and why and then hopefully I will be able to answer
> to your satisfaction.
Oh, sorry, I had quick look over function first time and do not noticed
how you handle return value from memcmp for @val argument.
I had not knew about this when wrote attribute resize (as I already said
our docs is incorrect in this part). Have to rewrite some parts. :-(
Anyone please update our docs, something like this:
Collation rule for attributes:
1. Type.
2. Name.
3. Lowest VCN (for attributes that can become non-resident) /
Attribute value (for always resident attributes).
Inode can have several attributes with same name and type if they are
always resident. But attributes that can become non-resident should
always have unique pair of type and name.
--
Best regards,
Yura
|