rsync : old file dates generating error during nfs rsync session:
Value Too large for defined data type
tim.conway at philips.com
tim.conway at philips.com
Fri Apr 12 09:19:02 EST 2002
Standard stuff. Many NFS server implementations set the high bit of the
mtime (signed, 32-bit integer) for something called "exclusive create".
NFS clients are supposed to ignore that bit, but some, notably SunOS, do
not. There is a fix for Solaris 7 and 8, but it fixes only NFSv3. If you
are accessing the NAS via NFSv2, it's not fixed. The date isn't really
1961, though your Solaris 8 server is printing it as such.
do a "perl -e 'print (stat(file))[9]", and you'll find that it's
>2147483647. Subtract 2147483648 from the number, and do a "perl -e
'print (gmtime(thenumberyougot))[5] + 1900", and you'll see a sensible
year.
In my case, the error wasn't corrected even in Solaris 8, so you're
clearly seeing the standard mtime bug. Mine seems to be atime, of all
things, but rather than fighting it, i wrote a custom sync program to run
inside the NAS devices, for at least part of the work.
Tim Conway
tim.conway at philips.com
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me.... Tim?"
"Wieprecht, Karen M." <Karen.Wieprecht at jhuapl.edu>
Sent by: rsync-admin at lists.samba.org
04/11/2002 07:44 AM
To: "'rsync at lists.samba.org'" <rsync at lists.samba.org>
cc: "Gelsie, Steven" <steveng at rocknroll.jhuapl.edu>
"Burk, Rick T." <Rick.Burk at jhuapl.edu>
"Thomas, Daniel J." <Daniel.Thomas at jhuapl.edu>
"'Michael.Salmon at uab.ericsson.se'" <Michael.Salmon at uab.ericsson.se>
(bcc: Tim Conway/LMT/SC/PHILIPS)
Subject: rsync : old file dates generating error during nfs rsync session: Value
Too large for defined data type
Classification:
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
karen.wieprecht at jhuapl.edu
---------------------------------
--
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
More information about the rsync
mailing list