How to detect renames?

[zoten]

Hi everyone and thanks for the great work!
Sorry if this can seem a silly question - and I hope it is - but I'm struggling to understand how to detect file renames (using inotify backend atm).
Example:

• touching a file triggers three events: [:created], [:attribute], [:modified, :closed] referring to the same path
• vim-ming a file produces a couple [:modified] more, but ends always with a [:modified, :closed]
• moving a file triggers instead two events: [:deleted], [:created] the first referring to the original path, the latter referring to the renamed file

I don't have here a clue on how to understand when a single [:created] event refers to a file rename, which is a use case I need to address. Am I missing something? Is there any reason I'm not seeing to collapse the MOVED_FROM and MOVED_TO events to :deleted and :created ?

Edit: Just as a note, I took a look on the original fs project. They allow the renamed attribute, but they also don't support the MOVED_FROM flag. I may be missing the reason for you not to support the renamed attribute, in that case I say sorry, but it may be enough to correctly handle renames (even if not knowing from which file).

Re-edit: I see that the desired behavior has been removed in f35b1e8806399c882306d0c9155bead25a89ef7b but, again, I don't get the ratio behind this choice

Thanks!

[falood]

Hey @zoten

as this pr mentioned #44, the reason we changed move_to event from rename to delete is when "deleting" a file through a graphical file manager, the file is not actually deleted, but is moved to the trash.
Let's talk about it, whether there's a way to handle both cases great.
we have several options:

1. move_from -> delete, move_to -> create
2. move_from -> delete, move_to -> rename
3. move_from -> ignore this event, move_to -> rename
4. move_from -> move_from, move_to -> move_to

[zoten]

Thanks @falood ,
I personally think the case in the mentioned PR could be managed slightly differently, like detecting when the renamed path goes to the trash bin, otherwise you cannot detect any non-deleting rename.
You still have the problem that you cannot link two file events (e.g. folder/file delete -> trash/file rename), but I see the same problem in the erlang version (that chooses option 3, as far as I can see)

When first starting to think for a patch I tried to consider option (4), which seems the more complete, but I fear I'm missing something (probably the flag parity between different notify/fsevent systems?)

What are your thoughts about it? :)

[falood]

I agree the trash bin event should be handled separately.
personally, I think option (4) is better.
Each backend has its own known_events list, it's ok to just handle the list well, and let the caller handle and process high level events like rename move_to_trash.

[zoten]

Aye, if (4) is acceptable it seems to me the more precise and allows the best granularity (each higher level event can be handled by software logic).

I updated PR with those changes if needed

[falood]

great! ♥ thanks