-c Option

[Paul LaMadeleine]

Actually,

         We have the problem here.  We have an NFS server mounted on a mix 
of Solaris, AIX, HP, True64, NT and VMS.  What seems to be happening is 
that something on the VMS side updates the file which creates a new 
version.  On the unix side the plain files is somehow linked to the new 
version but does not always have it's inode info updated.

         For those of you who don't know VMS and VMS file versioning, 
whenever a file is modified by VMS it creates another copy of the file with 
a new extention number.  For example, the first time you create a file x.x 
it will actually be labeled x.x;1.  The next time you modify this file, 
there will be two copies, x.x;1 and x.x;2 where x.x;2 is the newer file and 
any reference to x.x will reference the newest file.

         Now multinet (the TCPIP stack) on vms creates another file on NFS 
mounted shares without a ;# that is somehow linked to the newest 
file.  This is what the unix servers have the inode linked to.

         Hope this is clear, but it's the only time I've seen it happen myself.

         Paul

At 12:43 PM 5/30/02 -0400, Michael Montero wrote:
> > The only reason to use -c is if you have data which may be changed without
> > changing mtime, ctime or size (is there any case where that happens?).  It
>
>         That's great news.  I believe this applies to me just fine and I
>can turn off the checksum.  Quick question....can anyone explain to me
>when the data in a file might change without changing the mtime, ctime or
>size?  I'm not sure I've ever come across that before.  An example might
>help me determine if I can safely remove -c.
>
>Tim, thanks for the reply!
>
>
>
>--
>To unsubscribe or change options: 
>http://lists.samba.org/mailman/listinfo/rsync
>Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html