A Netapp NFS server containing a file (xxx) and a snapshot of the file (.snapshot/xxx) will give them the same inode number. Unfortunately, 'cp .snapshot/xxx xxx' (in order to recover the snapshot ve
<http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html> If source_file references the same file as dest_file, cp may write a diagnostic message to standard error; it shall do nothing more w
Yes. Use cp's --backup (-b) option. Then, cp can be sure that opening the destination file (for writing) will not destroy the source file. Using --backup has the added advantage that the destination
Well, whether source_file references the same file as dest_file is not quite clear. They have the same inode, yes, but different content. Tim. */ Attachment: pgpyF_69Ab9V5.pgp Description: PGP signat
Can someone make sure this patch works and let me know? Just apply it, build cp, and then run a command like ./cp .snapshot/F F for some file F, on a NetApp-backed file system. The above command shou
As Jim already wrote, POSIX is quite clear about that. Andreas. -- Andreas Schwab, SuSE Labs, address@hidden SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58C
I just tried it on a Solaris 8 host with a remote NetApp filesystem, and it sort of worked, but it had problems. 1. Patched GNU "cp .snapshot/weekly.1/F F" fails if F has not been changed since the s
Thanks for the quick work! If you are motivated, you might be able to find a solution yourself. You could try comparing the entire `struct stat's of two file/snapshot pairs, one where the snapshot is
The only difference that I found was the st_atime field. For example: $ ls -ltu .addressbook .snapshot/*/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 7 15:00 .snapshot/hourly.0/.addressbook -rw-r--r--
I recently installed Fedora Core 5 on a machine and downloaded the rsnapshot RPM (v1.2.1) from the Downloads section of www.rsnapshot.org. FC5 uses /bin/cp version 5.93, and this version doesn't like
Thanks for the bug report. However, this issue has already come up in the past: http://lists.gnu.org/archive/html/bug-coreutils/2006-02/msg00069.html http://lists.gnu.org/archive/html/bug-coreutils/
Eric-- Thank you for your swift and gracious reply, especially since I hadn't checked the mailing list archives to see whether the bug had already been noted. My bad. Whatever way rsnapshot decides t
We use GNU cp because of the -l option, but that's not available in other peoples versions of cp, so we also have our own clone of that functionality. Our version is somewhat slower, but is portable.
cpio is portable? That's news to me. I've been staying away from cpio ever since it massively screwed up one of my directory hierarchies due to its truncation of inode numbers to 16 bits. (This was o
In case you can try the build/test routine using the very latest snapshot tarball, here it is: http://meyering.net/cu/coreutils-6.7-dirty.tar.gz http://meyering.net/cu/coreutils-6.7-dirty.tar.gz.sig
http://meyering.net/cu/coreutils-6.7-dirty.tar.gz http://meyering.net/cu/coreutils-6.7-dirty.tar.gz.sig This includes the very latest changes from gnulib (as of an hour ago), so if you find a portabi
Last night I made another coreutils snapshot: http://meyering.net/cu/coreutils-6.7-dirty.tar.gz http://meyering.net/cu/coreutils-6.7-dirty.tar.gz.sig aka http://meyering.net/cu/coreutils-6.7-ss-2007-