I was troubleshooting a problem we were having with some files not rsyncing properly over an nfs mount (the destination device is a snapserver (NAS) that did not have native ability to receive streaming rsync info, that's why we were doing this rsync over an NFS connection to the snapserver).
Anyway, at first I thought this was just one of the quirks of the snapserver (it isn't native UNIX), but I discovered that I also had trouble accessing those files from UNIX NFS clients. The NFS server where the files really live (Solaris 8) could access them just fine. It turns out that the problem was because the date of the files was Nov 25, 1961 (before UNIX was around), and NFS didn't seem to handle that very well. Touching the file to give it a current date made the NFS issue go away, and rsync over the NFS connection then worked as well. When I searched google for this error a few days ago, I got some good tips about rebuilding a newer version of rsync with the off64_t flag (for large filesystems), but this solution didn't work in my situation. I'm therefore posting this message because I think I found a slightly different scnerio that causes this error. Perhaps it will save someone else some time. While trying to find the correct news group to post this to, I found a related posting where Michael Salmon explains this NFS behavior nicely (wish I'd seen this message a few days ago! ). If you are interested in this related explanation, it can be found at http://lists.samba.org/pipermail/rsync/2001-October/005002.html (thanks Michael!). Thanks, Karen Wieprecht --------------------------------- Karen Wieprecht Senior Unix Systems Administrator 11100 Johns Hopkins Road Laurel, MD, 20723 443-778-3075 [EMAIL PROTECTED] --------------------------------- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
