Description of problem: getxattr on an NFS File (on Net-App, on a Sun-NFS Server it seems to work) returns EIO, thus cp -p filea fileb prints error and aborts. With kernel 2.4.21-1.1931.2.389 cp -p had no problem, there getxattr syscall returns not implemented, what seems to be ignored by /bin/cp. On 2.4.21-1.1931.2.399 it seems to be partially implemented, what seems to be bad over NFS. Version-Release number of selected component (if applicable): 2.4.21-1.1931.2.389 How reproducible: On an NFS-Mounted Filesystem on a Net-App e.g. some /home/xy Steps to Reproduce: 1. cd /home/xy 2. touch a 3. cp -a b Actual results: prompt# cp -p a b cp: `a': Input/output error Expected results: no error Additional info: Tried on i686, x86_64 and ia64
Steve: didn't we fix this last week ?
Yes... I believe this is fixed in the latest version of taroon
This is still a problem, at least with Taroon Beta 2 on IA64. I am NFS mounting a directory exported from a Linux 2.4.19/i386 server, and I get: $ uname -a Linux tiger-1.topspincom.com 2.4.21-1.1931.2.399.ent #1 SMP Wed Aug 20 15:23:44 EDT 2003 ia64 ia64 ia64 GNU/Linux $ touch a $ strace -egetxattr cp -a a b getxattr("a", "system.posix_acl_access", 0x60000fffffffac80, 132) = -1 EIO (Input/output error) cp: `a': Input/output error With Taroon Beta 2 on x86_64, getxattr() gives ENOSYS and cp works fine: $ uname -a Linux swopteron2 2.4.21-1.1931.2.393.entsmp #1 SMP Wed Aug 13 21:26:37 EDT 2003 x86_64 x86_64 x86_64 GNU/Linux $ touch a $ strace -egetxattr cp -a a b getxattr("a", "system.posix_acl_access", 0x7fbfffee20, 132) = -1 ENOSYS (Function not implemented)
This seem to be fixed "again" with latest taroon kernel.... Linux celestica1.boston.redhat.com 2.4.21-1.1931.2.434.ent #1 SMP Tue Sep 16 03:49:44 EDT 2003 ia64 ia64 ia64 GNU/Linux
My apologies. RHN does not show any errata for Taroon beta 2 (Red Hat Enterprise Linux 3 AS Beta 2 (ia64)), which is why I thought my Taroon beta 2 install was up to date. However if I go to packages and look up kernel, I can see that kernel-2.4.21-1.1931.2.423.ent is actually available. This .423 kernel does indeed fix the problem.