source side

[Juergen Busam]

John Van Essen wrote:
> 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).

sorry about that, but after my problems I didn't trust the Domain
policies anymore and changed my mount command into:

mount -t smbfs -o username=user,password=pwd,ro //server/share /backup/sync

sorry, that I didn't mention it explicit before. I thought it is enough
to say I mount it read-only... sorry about this...
> 
> 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.

I did this, but the problem is still the same! thanks a lot for your
help and I hope that NetApp AND/OR RedHat have further ideas to solve
this BUG.

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