|
Home > Archive > Unix administration > January 2004 > rsync -u and --ignore-existing options don't work
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
rsync -u and --ignore-existing options don't work
|
|
|
| rsync serv: aix 4.3.3 ML11
client I am testing with: aix 4.3.3 ML11
I have an rsync server supplying files for the /usr/local
directory structure. When a client runs rsync it pulls over
several /usr/local directories and links are created in
/usr/local/bin to where the binaries actually reside.
Occasiionally, I want to drop a binary in /usr/local/bin
and not have rsync write over it with a link to the rsync
distribution. For example, I dropped a newer gzip binary
in /usr/local/bin and thought because the client ran rsync
with the -u option, it would not write over the newer binary,
but it did - and it re-created the symlink over to the rsync
distribution binary.
I compiled rsync v2.5.6 and tried using the --ignore-existing
to no avail - it still wrote over the newer binary I dropped
into /usr/local/bin
Is there a config or command option I am missing? I do not want
to have to write special "exclude" options into the rsync command
everytime a newer piece of software is put on a machine.
Does anyone have a solution or a command option that, perhaps,
I have overlooked?
Thanks!
-BR
| |
| Bill Marcum 2004-01-23, 5:08 pm |
| ["Followup-To:" header set to comp.unix.admin.]
On 5 Nov 2003 12:44:56 -0800, raver
<barbara_ries@hotmail.com> wrote:quote:
> rsync serv: aix 4.3.3 ML11
> client I am testing with: aix 4.3.3 ML11
>
> I have an rsync server supplying files for the /usr/local
> directory structure. When a client runs rsync it pulls over
> several /usr/local directories and links are created in
> /usr/local/bin to where the binaries actually reside.
>
> Occasiionally, I want to drop a binary in /usr/local/bin
> and not have rsync write over it with a link to the rsync
> distribution. For example, I dropped a newer gzip binary
> in /usr/local/bin and thought because the client ran rsync
> with the -u option, it would not write over the newer binary,
> but it did - and it re-created the symlink over to the rsync
> distribution binary.
>
"rsync -u" is not supposed to overwrite a destination file that is newer
than the source. Does your "newer" gzip perhaps have an earlier
timestamp than the "older" version (compiled from older source code)?
Or perhaps one of the systems has a clock that is way off?
--
You can go anywhere you want if you look serious and carry a clipboard.
| |
|
| Bill Marcum <bmarcum@iglou.com> wrote in message news:<k39o71-mhl.ln1@don.localnet>...quote:
> ["Followup-To:" header set to comp.unix.admin.]
> On 5 Nov 2003 12:44:56 -0800, raver
> <barbara_ries@hotmail.com> wrote:
> "rsync -u" is not supposed to overwrite a destination file that is newer
> than the source. Does your "newer" gzip perhaps have an earlier
> timestamp than the "older" version (compiled from older source code)?
> Or perhaps one of the systems has a clock that is way off?
The date on the system is accurate.
Here is the process I am going through to test this:
This is the current gzip on the system
/usr/local/bin/gzip -> ../gnu/gzip-1.2.4/bin/gzip
Here is the timestamp on that file:quote:
>ls -la ../gnu/gzip-1.2.4/bin/gzip
<snip> Mar 06 2001 ../gnu/gzip-1.2.4/bin/gzip
Then I remove the gzip link in /usr/local/bin and drop
in the new binary.quote:
>ls -lad gzip*
<snip> Nov 10 10:36 gzip
The next time rsync runs it recreates the link over to
.../gnu/gzip-1.2.4/bin/gzip
Here is the rsync command I am using to pull the files:
rsync -rlogputv --log-format "%o %f %l" <server>::Aix43/${dir} /usr/local
I should have included the above command in my first post.
Thanks!
-bries
|
|
|
|
|