source side
John Van Essen
vanes002 at umn.edu
Sat Jun 11 20:09:43 GMT 2005
On Sat, 11 Jun 2005, Juergen Busam <busam at gmx.net> wrote:
> Yes, the source side is a CIFS share on a NetApp filer and YES, they
> change everytime I run rsync and they go back another hour.
> no, they do NOT restore to their "normal" unchanged values, after
> unmounting and mounting again...
OK. Thanks for verifying that.
> they shouldn't change at all, because rsync shouldn't do anything on the
> source side, the CIFS share is mounted readonly AND the Windows Domain
> User has only read rights in this share....
According to your mount command that I quoted below, it is not mounted
read-only on the *nix side (there's no "ro" option).
I don't use windows shares, but I have a theory about what's going wrong.
Since the mount is not read-only, RHEL will be trying to update the
last-access times for directories and files that rsync reads. AFAIK,
last-accesss and last-modified timestamp updates are always done in
the same operation, so it's also setting the last-modified time. If
the smbfs/NetApp routine that handles that incorrectly processes a DST
flag, that can explain the hour shift. If the windows side accepts
a timestamp change operation even though its a read-only share (which
might apply only to opens and not to meta-data access), then this
combination explains your problem. To re-iteerate, this is not an
rsync problem - it's just rsync triggering some other bug.
Add an "ro" to your mount options and see if that makes the problem
go away. Other than that, I have no further help for you. Sorry.
Maybe someone with smbfs/NetApp experience can offer more advice.
John
> John Van Essen wrote:
>> In your original "timestamps" thread back on May 25:
>>
>> http://www.mail-archive.com/rsync@lists.samba.org/msg13496.html
>>
>> you said the source is a "windows share from a NetApp filer" that
>> is mounted on a RHEL3 box via:
>>
>> mount -t smbfs -o username=user,password=pwd //server/share /backup/sync
>>
>> Your timestamp example below seems to indicate a loss of the daylight
>> savings time flag, producing times that are an hour earlier. I think
>> that this is some kind of timestamp _reporting_ problem rather than a
>> timestamp _changing_ problem, and is related to the kernel routine
>> that translates smbfs data to unix fs data. Rsync's heavy disk usage
>> have exposed software shortcomings in the past and this may be yet
>> another example.
>>
>> Have you looked at the timestamps via the windows system to see if they
>> have actually changed when this "problem" happens?
>>
>> Do they change every time you run rsync and go back another hour each
>> time? Or do you unmount the windows share and remount it and the
>> timestamps are restored to their "normal" unchanged values?
>>
>> John
>>
>>
>> On Sat, 11 Jun 2005, Juergen Busam <busam at gmx.net> wrote:
>>
>>>I've ran a "ls -altr" on the source before syncing and after it and it
>>>definitely shows that the timestamps of the source side changed after
>>>rsync has finished. The destination side gets the timestamps of the
>>>source side before the sync.
>>>
>>>Example:
>>>
>>>bevor sync:
>>>-rwxr-xr-x 1 root root 572928 Feb 23 22:26 Accept_PatXfer.dot
>>>
>>>after sync:
>>>-rwxr-xr-x 1 root root 572928 Feb 23 21:26 Accept_PatXfer.dot
>>>
>>>destination shows
>>>-rwxr-xr-x 1 root root 572928 Feb 23 22:26 Accept_PatXfer.dot
>>>
>>>after the rsync run.
>>>
>>>
>>>The "problem hereby is, that the sourceside is mounted readonly!
>>>Nevertheless the timestamp gets changed...
>>>
>>>
>>>Wayne Davison wrote:
>>>
>>>>On Fri, Jun 10, 2005 at 09:27:42AM +1000, Juergen Busam wrote:
>>>>
>>>>
>>>>>I still have my formerly mentioned timestamp problem. IS rsync changing
>>>>>the timestamps on the sourceside?
>>>>
>>>>
>>>>No, rsync doesn't do anything on the source-side except read things
>>>>(unless --remove-sent-files is specified, in which case it also removes
>>>>things). If your timestamps on the source are changing, something else
>>>>is changing them. (You may wish to verify that the timestamps on the
>>>>source are the ones that are changing and not the destination -- rsync
>>>>updates the files when the timestamps are different, but you don't know
>>>>for sure which side has the changed timestamps unless you investigate.)
>>>>
>>>>..wayne..
More information about the rsync
mailing list