source side

[John Van Essen]

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..