rsync problem - not copying files

[Greebo]

Ok, here's where I'm at.

rsynch is failing to copy files.

It's creating directory structures (to a point) but then it can't seem to actually create the files.

I did it on a scaled down version - only one folder with just 3 files to consider, and it said it was trying to send one, got to 18%, and stuck, and on the destination, an empty file was created.

Ideas?

Anyway I can use rsynch in a pull mode instead of a push?

 

[jason]

Ok, here's where I'm at.

rsynch is failing to copy files.

It's creating directory structures (to a point) but then it can't seem to actually create the files.

I did it on a scaled down version - only one folder with just 3 files to consider, and it said it was trying to send one, got to 18%, and stuck, and on the destination, an empty file was created.

Ideas?

Anyway I can use rsynch in a pull mode instead of a push?

Yes, you can run rsync in a pull instead of a push...just change the order of the variables.

push: rsync -av --delete -e ssh /local/path user@host:/remote/path
pull: rsync -av --delete -e ssh user@host:/remote/path /local/path

PM me and I can remote in to help you out. I won't need your login....we can just do it in a remote support session.

 

[Greebo]

ah, i'll try it from the new server then

 

[Greebo]

that seems to be working much better, thanks.

 

[jason]

that seems to be working much better, thanks.

No problem...

 

[jesse]

Keep in mind that -v does not give you full verbose output. The more v's you add, the more detailed the output will be.

-vvvv provides more output than -v.

Most likely a more verbose output would show you the problem.

 

[Greebo]

I'm sure it would, but by doing it as a pull instead of a push, the file list took only about2 minutes to produce (instead of about 15), and the downloads are moving along nicely (4.5k of 11.5k so far complete).

So I figure if it didn't work with A, but it works with B, f A, i dont care why it didn't work.

 

[jason]

I'm sure it would, but by doing it as a pull instead of a push, the file list took only about2 minutes to produce (instead of about 15), and the downloads are moving along nicely (4.5k of 11.5k so far complete).

So I figure if it didn't work with A, but it works with B, f A, i dont care why it didn't work.

lol

You could also add a -z to see if compression helps.

 

[Greebo]

Already am:
rsync -rlptvz --progress --delete -e ssh <nunya> <ainttellin>

Once its done, I intend to post an attachment and run it again, see how long it takes.

 

[Greebo]

attachment for rsync testing purposes

 

[Greebo]

OK that was fast.

 

[mikea]

I'm sure it would, but by doing it as a pull instead of a push, the file list took only about2 minutes to produce (instead of about 15), and the downloads are moving along nicely (4.5k of 11.5k so far complete).

So I figure if it didn't work with A, but it works with B, f A, i dont care why it didn't work.

Ta think. When you work copying files off a server that's overloaded and doesn't run the application very well...the copying job doesn't go very fast.

With a "pull" you're putting the hard work on the new system that is working well.

 

[KennyFlys]

attachment for rsync testing purposes

Proof that looks are deceiving!

 

[Greebo]

Ta think. When you work copying files off a server that's overloaded and doesn't run the application very well...the copying job doesn't go very fast.

With a "pull" you're putting the hard work on the new system that is working well.

That occurred to me, but doesn't explain why it couldn't even put 1 file up in a tiny test.