Re: [flux-dev] Status update

[Martin Lippert <mlippert@xxxxxxxxx>]

Hey Fjodor,

> Hi! Ok, I see your point.
> 1) What do you think about taking into account content hash?
> For example like this:
> https://github.com/eclipse/flux/commit/e9fdcddbe590a16fd95ba0add4050b7e6302e381

+1

I hope you are doing extensive testing with all your changes…

> 2) Fingerprints. In my opinion, it is better to implement fingerprints using UUID.  I had spend some time to figure out, how it should work, however I think these changes are too complex for this GSOC scope. 
> I hope to continue work on them after GSOC.

Sounds good.

Cheers,
-Martin




> Fjodor
> 
> 2016-08-18 11:30 GMT+03:00 Martin Lippert <mlippert@xxxxxxxxx>:
> Hey!
> 
> If you remove that check for the resource to already exist, you can easily end up in endless ping-pong-games among the nodes that participate in the resource syncing.
> 
> Imagine something like this:
> node A identifies a new resource and sends out a “resourceCreated” event.
> node B receives the resourceCreated event, creates the resource locally, and sends out an event “resourceCreated” itself.
> node A receives the resourceCreated event, creates the resource locally, and sends out an event “resourceCreated” itself.
> …
> 
> You need to break this loop and avoid endless notifications.
> The current implementation does this by checking whether a resource already exists locally in case a “resourceCreated” event arrives.
> I think this is not perfect, since the content of that created resource could be different from the content of the locally existing resource. So it would be better to send a fingerprint of the resource around to double check for that. It would also break the loop and would be much better.
> 
> However, you still would need something like a “previous version” fingerprint, too, to avoid overriding changes and detect collisions. But that applies to “resourceChanged”, too.
> 
> Hope this helps!
> -Martin
> 
> 
> 
> 
> 
> 
> > Am 18.08.2016 um 09:41 schrieb Vershinin Fjodor <fjodor@xxxxxxxxxxxxx>:
> >
> > Hi!
> > Can you try to move file from outside into this directory, replacing original one?
> > For example: touch ../file; mv ../file file;
> > Also, you can try to move file from other partition, for example flash drive.
> > I had noticed, if I move files on the same partition, then I get MOVE_TO event;
> > however on different partitions my original file is deleted, created new one, and content
> > MOVE_TO case cannot be handled by flux, because resource already exists. I am trying to figure out how to fix this.
> > The first idea is to ignore if resource exists or not on node.js side as proposed in patch. What do you think?
> > Fjodor
> >
> >
> > 2016-08-18 10:18 GMT+03:00 Martin Lippert <mlippert@xxxxxxxxx>:
> > Hey Fjodor,
> >
> > not sure what exactly I should do, but here is what I did on my OS X machine:
> >
> > - started your app, watching a directory
> > - edited a file in that directory and pressed save (in the text editor)
> >
> > -> test.txt ENTRY_MODIFY
> >
> > - copied a file with the same name into that directory and pressed “replace” in the dialog
> >
> > -> test.txt ENTRY_MODIFY
> >
> >
> > Does that help?
> >
> > Cheers,
> > -Martin
> >
> >
> >
> > > Am 17.08.2016 um 14:12 schrieb Vershinin Fjodor <fjodor@xxxxxxxxxxxxx>:
> > >
> > > For example, when I edit file on my linux machine, gnome editor creates temporary file and on saving it moves temporary file replacing original one. From java fs watcher's perspective it looks like a new file was created with the same name. Flux cannot handle this.
> > > I think, this case can be handled using the same way, as flux handles changing existing files. What do you think?
> > > I just tried to reproduce this issue on different machines. On Windows machine, when I try replace file, I get this sequence:
> > > "ENTRY_DELETE
> > > ENTRY_CREATE
> > > ENTRY_MODIFY"
> > > On latest linux kernel I have the same behavior. On unbuntu LTS, I get "ENTRY_CREATE" only.
> > > So, it looks like kernel issue. Martin, could you have a look at Mac machine, if it is possible?
> > > <App.java>_______________________________________________
> > > flux-dev mailing list
> > > flux-dev@xxxxxxxxxxx
> > > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > > https://dev.eclipse.org/mailman/listinfo/flux-dev
> >
> > _______________________________________________
> > flux-dev mailing list
> > flux-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/flux-dev
> >
> >
> >
> > --
> > Thanks,
> > Fjodor
> > <repository-message-api.js.patch>_______________________________________________
> > flux-dev mailing list
> > flux-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/flux-dev
> 
> _______________________________________________
> flux-dev mailing list
> flux-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/flux-dev
> 
> 
> 
> -- 
> Thanks,
> Fjodor
> _______________________________________________
> flux-dev mailing list
> flux-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/flux-dev