Share

ZSyncer

Tracker: Bugs

8 problem with acquisition (grave) - ID: 1708093
Last Update: Comment added ( nobody )

I place a folder named A in the root of my portal, and inside this folder
another document named A.

If I remove the A (document) inside the folder with "manage_deleteRemote"
all is ok.

If, after that, I push again the document A inside the folder with
"manage_pushToRemote" I find that the A document has overwritten the folder
A on the target server and so I find the document A in the portal root.

This seems a problem similar to the 1161733 but it seems is not fixed at
all.


Keul ( keul ) - 2007-04-26 14:24

8

Open

None

Nobody/Anonymous

None

None

Public


Comments ( 6 )




Date: 2008-12-28 11:01
Sender: nobody

i0P1fq <a href="http://jtkqsopdrkll.com/">jtkqsopdrkll</a>,
[url=http://itskmrsdredv.com/]itskmrsdredv[/url],
[link=http://yllpblykhyyz.com/]yllpblykhyyz[/link],
http://summdsycsxuq.com/


Date: 2007-05-02 13:19
Sender: keul


I try with the 0.7.2 unreleased, from CVS as you request... nothing
changed!
But I can report here some new info... it seems like its not working only
in Plone site... let's begin (is a little long description).

Follow my current configuration problem:

Source server contains an "intranet" Plone site and inside that I put the
ZSyncer object ("zsync_source")
Target server contains a "Portale" Plone site and inside that I put
another ZSyncer object ("zsync_target")

I changed the test a little for the last time: inside source portal root
(at the same level of the ZSyncer object) I added a folder with title
"Level 1". Inside this I put "Level 2" and then "Level 3" and finally
inside the last I put a document "Level final". ALL this objects keeps the
same id (for example "dummyid").

Now I don't work using my transitions script anymore, but directly the
interface of the ZSyncer source object (like you ask).

1) from source host in "/intranet/zsync_source" I put folder "Level 1" to
the target using ZSyncer UI. [OK].

2) from target host in "/Portale/dummyid/dummyid" (so I am inside "Level
2" folder) I delete the "Level 3" [OK].

3) from source host in "/intranet/zsync_source" I begin to navigate using
the ZSyncer interface. I find that "Level 3" is missing on the target
[OK].

4) From here I use PUT command for themissing folder.
Now problem begins. On the source server I use again ZSyncer UI and I go
back to the "intranet/dummyid/dummyid"... now I don't find the "missing"
message but I read "ok". (This is wrong but I don't know if this is a bug
or is normal... may be that ZSyncer check only the presence of the id?
mmhhhh...)

5) If I go the target server I find that the "Level 2" folder is missing.
My current tree is "Portale - Level 1 - Level 3 - Level final".

So the problem is here. Every time I use the PUT command, after deleting
the remote copy, the current folder on the target server is "eaten".
If I repeat the test, deleting only the "Level final" document (so using
the PUT button from "intranet - Level 1 - Level 2 - Level 3" just after
deleting the document on the target server), I get this tree structure:
"Portale - Level 1 - Level 2 - Level final".


After this all I repeat the same test outside the Plone sites but keeping
the structure, so using two ZSyncer object inside another object.
I create on the source server, in the Zope root a (Zope) Folder "TMP".
Inside this I create a (new) zsync_source object and I create the whole
directory structure ("Folder 1",...) but using only Zope Folder. For "Level
final" I used a "File" text object.

I create the equivalent structure on the target server and I configure
them to work togheter.

In this case (I really don't know why) all is working correctly... no
folder is eaten in the process!

I will attach 2 screenshots of my configuration of the "bad working
couple" (no problem for the password... I'm using intranet develop
servers). The two that are working have the same configuration (of course,
different path property on the source server).

I hope this may help. Tomorrow I will try the unit test.
File Added: notworking.tar.gz


Date: 2007-04-30 04:49
Sender: slinkpProject AdminAccepting Donations


Can you try again with current CVS code?
(Just committed now; it might take a while to show up in anonymous
checkouts... to verify, check the $Id$ tag in ZSyncer.py, it should be at
least "$Id: ZSyncer.py,v 1.101 2007/04/30 04:43:35 slinkp Exp $" ... if you
don't see an $Id tag at all, it's too old)

I've written some a test case that should reproduce this bug, and another
for
bug 1161733, and both tests pass.

If you still have the problem:

- Can you reproduce in "plain" zope - not using Plone?

- Even better, can you look at tests/test_ZSyncer.py and see if you can
come up
with a test case that fails? See eg. TestRemoteAcquisition

- If you can't do that, can you email me your complete zsyncer
configuration on both the source and destination?
(screenshot is fine... you should remove authentication and host
information of course...
I'm interested in the path settings and which options you've got turned
on.)



Date: 2007-04-26 14:47
Sender: slinkpProject AdminAccepting Donations


Thanks. I unfortunately don't know when I can get to this, I have very
little time for non-paying projects right now.


Date: 2007-04-26 14:41
Sender: keul


I'm using ZSyncher 0.7.0 on a Plone site 2.1.4

I use ZSyncher to perform copy of the current object to a remote server on
some workflow transitions... I have this problem when the folder name is
the same of the default page inside.

Looking at the 0.7.1 version I found no so important changes, so we didn't
upgraded...


Date: 2007-04-26 14:35
Sender: slinkpProject AdminAccepting Donations


ouch. What version of zsyncer?


Log in to comment.




Attached File ( 1 )

Filename Description Download
notworking.tar.gz Two screenshot fo the source and target configuration properties Download

Changes ( 2 )

Field Old Value Date By
File Added 227501: notworking.tar.gz 2007-05-02 13:19 keul
priority 5 2007-04-26 14:24 keul