[execnet-dev] RSync Issue

[Charles Solar]

Sorry could not get around to testing this out today, i will get this
installed next time I have a chance to run my app.
Oh yea, completely forgot about the test case, I will get a small
package setup to illustrate too.

Charles

On Tue, Jul 27, 2010 at 12:47 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Charles,
>
> so i think that rsyncing symlinks should now work reaonsably well.
> I used your patches as a starting point but also added tests and made
> sure permissions are also transferred for directories.  Could you verify
> that after installing
>
>    http://hudson.testrun.org/view/pytest/job/execnet-sdist/lastSuccessfulBuild/artifact/.tox/dist/execnet-1.0.8a1.zip
>
> working with symlinks works for you?
>
> Also, i am still interested in a small failing test case for the other issue
> where you could not use RSync later on.
>
> thanks & best,
> holger
>
> On Mon, Jul 12, 2010 at 17:16 -0500, Charles Solar wrote:
>> I'll make up a small test case but just so I do not forgot I found
>> another bug dealing with symlinks.
>> I think that all relative symlinks are broken, or else I do not
>> understand how they could have worked before.
>> I saw it be having a structure like this rsync:
>>
>> lib/
>>    libnet.so -> libnet.so.1.0.0
>>    libnet.so.1.0.0
>>
>> What it created on the remote side was
>>
>> lib/
>>   libnet.so -> /tmp/rsynctemp/libnet.so.1.0.0
>>   libnet.so.1.0.0
>>
>> The link on the remote side did not include the lib subdir in the
>> link.  After looking at the code I fixed it up but I do not think they
>> should be working at all since the code atm only works if the symlink
>> is in the root dest directory.
>>
>> Ill send in a patch for you to look at.
>>
>> Charles
>>
>> On Sun, Jul 11, 2010 at 5:36 AM, holger krekel <holger at merlinux.eu> wrote:
>> > Hi Charles,
>> >
>> > On Fri, Jul 09, 2010 at 10:03 -0500, Charles Solar wrote:
>> >> It would appear that RSync will only work with brand new gateways that
>> >> have not had any other operations run on them.  Is this intentional?
>> >
>> > No.  Sounds like a bug.
>> >
>> >> For example, I do something like
>> >>
>> >> gw = execnet.makegateway( "ssh=foobar" )
>> >> gw.remote_exec( mybootstrapper )
>> >>
>> >> ... then later I want to rsync ...
>> >>
>> >> rsync = execnet.RSync( "/tmp/foobar" )
>> >> rsync.add_target( gw, "/tmp/barfoo" )
>> >> rsync.send()
>> >>
>> >> I get remote EOFErrors
>> >>
>> >> File "execnet-1.0.6-py2.7.egg/execnet/rsync.py", line 126, in send
>> >>     self._end_of_channel(channel)
>> >>   File "execnet-1.0.6-py2.7.egg/execnet/rsync.py", line 44, in _end_of_channel
>> >>     channel.waitclose()
>> >>   File "execnet-1.0.6-py2.7.egg/execnet/gateway_base.py", line 377, in waitclose
>> >>     raise error
>> >> exceptions.EOFError: expected 1 bytes, got 0
>> >>
>> >> If I however create a brand new gateway to give to rsync it works fine.
>> >>
>> >> I would think that since rsync just creates a new channel on the
>> >> gateway that it should work on existing 'old' gateways.
>> >
>> > yip. Myself i only used it for doing things at the beginning, it seems.
>> > Do you have or could you try to find an repeatable minimal example?
>> >
>> > best,
>> >
>> > holger
>> >
>>
>
> --
>