> On Sun, 2002-05-26 at 00:03, Tang Lingbo (Allan) wrote:
> > Hi,
> > One of the attached files is used to hit the bug as following,
> the patch is
> > my solution:
> > A. set a EA with 10 chars (name length + value length)
> > B. change above name's value with chars more than 32
> > If we used the EA through lib, the operations seems OK because it
> > has never used XATTR_REPLACE flag.
> > The patch will solve the problem.
> > Regards,
> > Allan
> The patch has problems I think:
> The old code would remove the existing value of the attribute, it
> would then calculate if the replacement attribute fitted in the
> inode. The new code will only put the new attribute inside the inode
> if both the old and the new attribute values - along with all other
> attributes still fit in the inode.
> Can you expand more on what you think is going wrong with the existing
> Steve Lord voice: +1-651-683-3511
> Principal Engineer, Filesystem Software email: lord@xxxxxxx
In the 1.1 release, the EA value will be set as the following rountines:
(Assume the initialization format of EA is INLINE)
1. lookup the EA's name
2. if found it and input flags have XATTR_REPLACE, remove it
3. calculate the space for new value
4. if the newsize more than INLINE, change the format to EXTENT
5. lookup the EA again
6. if found it and input flags have XATTR_REPLACE, remove it. otherwise, report
Then, the EA has been lookup twice, but maybe it has been remove at the first
This scenario happened when I initialize a small EA on one inode, and anyone
only replace it with their own's value on this name. Before any modifications,
of this name must be existed. otherwise, report error.
Of course we can implement this function by
2) if succeed, setxattr without XATTR_REPLACE.
but anyway, I don't think the current routines are so match with XATTR_REPLACE.