AnantLabs / big5sync

Automatically exported from code.google.com/p/big5sync
1 stars 0 forks source link

[SystemLogicLayer] Folder Deletion (Real-time) is not consistent #11

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Copy a folder with some files into one of the monitored folders
2. Wait for it to be synced across the other tag folders
3. Delete the folder

What is the expected output? What do you see instead?
Deletion should propagate. However, the output in this case is random. 
Sometimes it deletes, at other times the folder is recreated, and sometimes 
nothing happens.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by sohyuanc...@gmail.com on 11 Mar 2010 at 11:28

GoogleCodeExporter commented 9 years ago
When a folder of files (called it A) is copied to a watch path, after it is 
synced 
to the other tagged folders, immediately delete A from where it is 1st copied 
to 
will cause it to recreate. The reason is when A is copied to another tagged 
folder, 
a create event will be fired from the 2nd tagged folder. At this time before 
the 2nd 
tagged folder asked for a sync, A is gone so a sync will recreate A in the 
first 
folder.

When a folder of files (called it A) is copied to a watch path, after it is 
synced 
to the other tagged folders, immediately delete A from the 2nd folder will 
produced "nothing happen". The reason is when A is copied to another tagged 
folder, 
a create event will be fired from the 2nd tagged folder. At this time before 
the 2nd 
tagged folder asked for a sync, A is deleted at the 2nd folder. The monitor 
will 
treat this as a temp file (a create follow by a delete immediately) so there 
will 
not be a sync.

If anyone can understand what I trying to say, suggest a solution if you have 
any.

Original comment by kohcherg...@gmail.com on 11 Mar 2010 at 5:25

GoogleCodeExporter commented 9 years ago
Hi Cher Guan,

I tried to implement a folder lock but it seems it is not possible. Still 
looking 
into it. One suggestion I have will be to do the following:

1. Event detected.
2. If event is folder create event,
   Check all subsequent file events. If they are a child of the folder that was 
created, simply send them over (no need for the delay).
   This should speed up the time it takes for your events to be fired, hopefully you 
can handle the second delete properly then :)

Original comment by sohyuanc...@gmail.com on 12 Mar 2010 at 6:50

GoogleCodeExporter commented 9 years ago
Issue 14 has been merged into this issue.

Original comment by sohyuanc...@gmail.com on 15 Mar 2010 at 2:37

GoogleCodeExporter commented 9 years ago
Added to http://code.google.com/p/big5sync/wiki/KnownIssues09

Original comment by sohyuanc...@gmail.com on 16 Mar 2010 at 7:37

GoogleCodeExporter commented 9 years ago
Issue 15 has been merged into this issue.

Original comment by sohyuanc...@gmail.com on 16 Mar 2010 at 7:37

GoogleCodeExporter commented 9 years ago

Original comment by gohkhoon...@gmail.com on 26 Mar 2010 at 4:14

GoogleCodeExporter commented 9 years ago
Refer to issue179 for some limitation

Original comment by kohcherg...@gmail.com on 31 Mar 2010 at 6:36