On Thu, 2007-11-01 at 08:36 +0100, Jim Meyering wrote: > Fixing this for you may be tricky, since it sounds like > your file system cannot be POSIX-compliant. > > But first, have you tried a recent snapshot? > > http://meyering.net/cu/coreutils-6.9-ss.tar.gz > http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig > > There have been changes in this area since 6.9. > If that still fails, I suggest you run cp under strace or > a debugger to see precisely which syscall is failing. Let us know. > The changes that I think are giving you trouble > were required to eliminate some race conditions
Hello, Thank you for investigating our issue. This destination location is certainly not fully POSIX compliant. It's a method NetApp has developed to allow UNIX user access to be controlled by Windows ACLs. Using the recent snapshot exhibits the same behavior. Running strace using cp v6.9-354-68c33a produces the following... [EMAIL PROTECTED]:/p/inet->strace /usr/local/bin/cp /root/cron /p/inet [snip] stat64("/p/inet", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 stat64("/root/cron", {st_mode=S_IFREG|0644, st_size=486, ...}) = 0 stat64("/p/inet/cron", 0xbfb66bf4) = -1 ENOENT (No such file or directory) open("/root/cron", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0 open("/p/inet/cron", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = -1 EPERM (Operation not permitted) write(2, "/usr/local/bin/cp: ", 19/usr/local/bin/cp: ) = 19 write(2, "cannot create regular file `/p/i"..., 41cannot create regular file `/p/inet/cron') = 41 write(2, ": Operation not permitted", 25: Operation not permitted) = 25 write(2, "\n", 1 ) = 1 close(3) = 0 close(0) = 0 close(1) = 0 close(2) = 0 exit_group(1) = ? The resultant destination file is created, but left empty by 'cp'. A second 'cp' will succeed since the file was created by the first 'cp'. Running strace using cp v6.6 successfully copies the file, and produces the following... [EMAIL PROTECTED]:/p/inet->strace /usr/local/bin/cp /root/cron /p/inet [snip] stat64("/p/inet", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 stat64("/root/cron", {st_mode=S_IFREG|0644, st_size=486, ...}) = 0 stat64("/p/inet/cron", 0xbf8e5954) = -1 ENOENT (No such file or directory) open("/root/cron", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0 open("/p/inet/cron", O_WRONLY|O_CREAT|O_LARGEFILE, 0644) = 4 fstat64(4, {st_mode=S_IFREG|0777, st_size=0, ...}) = 0 read(3, "[EMAIL PROTECTED]"..., 32768) = 486 write(4, "[EMAIL PROTECTED]"..., 486) = 486 close(4) = 0 close(3) = 0 close(1) = 0 close(2) = 0 exit_group(0) = ? The new open() call causes cp to terminate. Is it the O_EXCL causing this? What concerns me is the following from the open() man page... O_EXCL is broken on NFS file systems; programs which rely on it for performing locking tasks will contain a race condition. Best regards, Clarence Donath _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils