hi Mark,
> Okay, I just tried with a cvs from last night and the problem persists
>
> localhost me # cp --parents -pRdf /usr/local/share /home
> cp: preserving permissions for `/home/usr/local/share/doc': Invalid argument
> cp: preserving permissions for `/home/usr/local/share/man/man1': Invalid
> argument
> cp: preserving permissions for `/home/usr/local/share/man': Invalid argument
> cp: preserving permissions for `/home/usr/local/share/mindi': Invalid
> argument cp: preserving permissions for `/home/usr/local/share/mondo':
> Invalid argument cp: preserving permissions for `/home/usr/local/share':
> Invalid argument
Do these files actually have ACLs set on them? (eg. what output does
"chacl -l /home/usr/local/share/doc" produce?)
Going back to your original mail...
On Mon, Jun 03, 2002 at 10:01:36PM +0000, mark wrote:
> Hi
>
> I've been having problems using the following with my xfs fs
>
> cp --parents -pRdf /usr/local/share/mondo /home/mondo.scratch.1050/
> ...
> direction. I have a small ext3 partition where the comand works fine but its
> smaller and different files are involved so this may not be a proof.
Are you using the ext2/3 ACL patches in your kernel? This would be
interesting to tell whether this is an XFS or a fileutils problem.
> SYS_229(0x8054e78, 0x4d286327, 0xbff72684, 0x84, 0x62) = -1 E2BIG (Argument
> list too long)
OK, so this one we know now is fixed in cvs (getxattr == SYS_229),
and was an XFS problem.
> stat64("/usr/local/share/mondo", {st_dev=makedev(3, 5), st_ino=25175423,
> st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096,
> st_blocks=0, st_size=32, st_atime=2002/06/03-21:59:11,
> st_mtime=2002/06/03-14:18:36, st_ctime=2002/06/03-14:18:36}) = 0
> SYS_226(0x8054df0, 0x4d286370, 0x8054f08, 0x1c, 0) = 0
> SYS_229(0xbff73b9c, 0x4d28633f, 0xbff728b4, 0x84, 0x4d26308d) = -1 ENODATA
> (No
> data available)
> SYS_226(0x8054df0, 0x4d286388, 0x8054ea8, 0x4, 0) = -1 EINVAL (Invalid
> argument)
[ugh, it would help to have strace to know about these new syscalls,
then we could see the (all-critical) name of this extended attribute
which we're trying to manipulate above.]
SYS_226 is setxattr, so we're trying to set an attribute, but size 0x4
looks very small. What does this command say for one of these failing
files:
getfattr -e hex -d -m . <file>
Another piece of useful information, in addition to the strace output,
would be the output from ltrace showing which routines are calling the
failing library routines.
thanks.
ps: this is an IA32 machine right?
--
Nathan
|