rsync - Apr 2002 - rsync : old file dates generating error during nfs rsync session: Value Too large for defined data type

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@jhuapl.edu
---------------------------------

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@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@jhuapl.edu>
Sent by: rsync-admin@lists.samba.org
04/11/2002 07:44 AM

 
        To:     "'rsync@lists.samba.org'"
<rsync@lists.samba.org>
        cc:     "Gelsie, Steven" <steveng@rocknroll.jhuapl.edu>
"Burk, Rick T." <Rick.Burk@jhuapl.edu>
"Thomas, Daniel J." <Daniel.Thomas@jhuapl.edu>
"'Michael.Salmon@uab.ericsson.se'"
<Michael.Salmon@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@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