Ticket #30 (closed defect: wontfix)
Renaming directory
| Reported by: | Linda Octalina <linda_octa@…> | Owned by: | |
|---|---|---|---|
| Priority: | major | Keywords: | |
| Cc: | ward@…, linda_octa@… | Launchpad Bug: |
Description
Hi
After lots of try and error, I found another similar bugs from http://trac.dbzteam.org/pyinotify/ticket/20. The fixes that you gave me on the top it's only work for the direct directory.
Example of this:
Directory Structure:
Dir1
Rename Dir1 to DirNewName?, the pyinotify can capture the event.
But when I try to rename Test.txt, pyinotify still use the old Dir1/Dir2/Test.txt path instead of DirNewName/Dir?2/Test.txt
Is there any workaround or is this a bugs?
Thanks,
Linda
Attachments
Change History
comment:2 Changed 10 months ago by seb
- Status changed from new to closed
- Resolution set to wontfix
Hi Linda,
Great to hear from you, I'm afraid in this case there is nothing we can do because the kernel doesn't provide us with enough information.
When a watched directory is moved IN_MOVE_SELF is emitted by the kernel but it does not piggyback the new pathname with it. Usually the related events IN_MOVED_FROM and IN_MOVED_TO are used to correlate this new pathname. Therefore when these two events are not emitted it is not possible to correctly deduce the new pathname.
Your example illustrate this case, when dir2 is moved (renamed) inside dir1 the source directory dir1 and the destination directory dir1 were already watched therefore the renaming is correctly inferred. But, when the top directory dir1 is moved no IN_MOVED_FROM event won't never be emitted by the kernel because dir1/.. is not watched itself, thus the renaming can't be correctly inferred. Note that even if the naming is wrong the directory is always watched!
My only advice in this case is to always watch a top directory which is not intended to be moved.
Cordially,
