plamadeleine at lightbridge.com
Thu May 30 10:14:01 EST 2002
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.
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:
>Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
More information about the rsync