-
-
Notifications
You must be signed in to change notification settings - Fork 696
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve handling of rename events on macOS #750
Improve handling of rename events on macOS #750
Conversation
Since this inode information in FSEvents is available only on Mac OSX 10.13 and later, this PR drops support for previous versions. I hope this isn't a blocker since OSX 10.12 is no longer maintained. |
Thanks @samschott!
Does that mean you will open a PR to handle that? :) I am OK to drop macOS 10.12 support 👍 I'll be able to do a review tomorrow (French timezone), could you add a line in the chagelog about the 10.12 support drop? There may be other places where the minimum macOS version is described, but I could do it before the release then. WDYT @CCP-Aporia? |
This is the PR that handles that. Case-changes should now be fine, see the added test Yeah, I'll add the information to the change log. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor review.
Yes, I just saw the test... Sorry :) |
Also, this is my first time coding anything in C. I think I have eliminated all segfaults and possible issues. But please have a very careful look at the extension module! |
Co-authored-by: Mickaël Schoentgen <[email protected]>
FTR I plan to move tests to GitHub Actions soon, because Travis-CI is a pain. |
…watchdog into improve-rename-handling-macos
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First of all, thanks a lot! 👍 This looks great overall. :-)
For the requested changes, please see the inline comments. Basically, increasing the reference count on the created PyObject
instances in those places cause a memory leak.
src/watchdog_fsevents.c
Outdated
CFNumberGetValue(cf_number, kCFNumberSInt64Type, &c_int); | ||
|
||
py_long = PyLong_FromLong(c_int); | ||
Py_INCREF(py_long); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PyLong_FromLong
returns a new reference, so there's no need to call Py_INCREF
here. :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, thanks!
src/watchdog_fsevents.c
Outdated
py_string = PyUnicode_FromString(c_string_ptr); | ||
} | ||
|
||
Py_INCREF(py_string); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PyUnicode_FromString
returns a new reference, so there's no need to call Py_INCREF
here. :-)
Just saw that |
This reverts commit 75afbd2.
this is the case for kFSEventStreamEventFlagRootChanged
Two more changes which I have made:
|
The handling of those events sure does look odd, and I wouldn't be surprised if there's an easier way of expressing what we need to guard there. :-)
Oh, that's an interesting one, there's potential for crashes and memory leaks here. It's necessary to |
Maybe I should have read the Python/C API docs first... I've hopefully fixed all issues with the inode attribute now 🤞 |
Co-authored-by: Mickaël Schoentgen <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The C extension looks good to me, so from my point of view this can get merged. 👍
Great work @samschott! Thanks for the review @CCP-Aporia 💪 |
Just for future reference, I have tested which events get emitted now when a user edits a file in TextEdit or a similar editor:
This is more verbose than the old emitter but seems quite sane to me. Note the |
* Fix installation of Python 3.7.9 on Windows (#705) * [windows] winapi.BUFFER_SIZE now defaults to 64000 (instead of 2048) To handle cases with lot of changes, this seems the highest safest value we can use. Note: it will fail with `ERROR_INVALID_PARAMETER` when it is greater than 64 KB and the application is monitoring a directory over the network. This is due to a packet size limitation with the underlying file sharing protocols. https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-readdirectorychangesw#remarks Also introduced `winapi.PATH_BUFFER_SIZE` (defaults to `2048`) to keep the old behavior with path-realted functions. * [mac] Regression fixes for native fsevents (#717) * [mac] Fix missing event_id attribute in fsevents (#722) * [mac] Return byte paths if a byte path was given in fsevents (#726) * Pin py.test to a version that supports 2.7 * Disable pypy2 tests on Windows They hang and timeout after 6 hours for some unknown reason * [mac] Add compatibility with old macOS versions (#733) * Ensure version macros are available * Uniformize event for deletion of watched dir (#727) * [inotify] Add support for the IN_CLOSE_WRITE event (#747) * [mac] Support coalesced fsevents (#734) * Add `is_coalesced` property to `NativeEvent` So that we can effectively decide if we need to perform additional system calls to figure out what really happened. * Replace `NativeEvent._event_type` with `repr()` support It's more pythonic, and the `_event_type` implementation wasn't quite usable anyway. NB: the representation is not truly copy/paste python code if there is a double quote inside event.path, but that should be a rare case so we don't add the expensive special case handling there. * Allow running tests with debugger attached Some Python debuggers create additional threads, so we shouldn't assume that there is only one. * Request notifications for watched root * Expect events on macOS instead of using `time.sleep()` It might be even better to check for the emitter class, as opposed to platform * Add exception handling to FSEventsEmitter Reduce the amount of 'silent breakage' * Use sentinel event when setting up tests on macOS So that we can avoid a race between test setup and fseventsd * Improve handling of coalesced events * Revert accidental platform check change * Fix renaming_top_level_directory test on macOS * Generate sub events for move operations * Remove `filesystem_view` again While the `filesystem_view` helps with filtering out additional `FileCreatedEvent`+`DirModifiedEvent` pairs then it also introduces a huge amount of edge cases for synthetic events caused by move and rename operations. On top of that, in order to properly resolve those edge cases we'd have to go back to a solution very similar to the old directory snapshots, with all the performance penalties they suffered from... As such I think it's better to acknowledge the behaviour for coalesced events instead, and thus remove the `filesystem_view` again. * [mac] Improve handling of rename events (#750) * drop support for macOS 10.12 and lower Co-authored-by: SamSchott <[email protected]> Co-authored-by: Boris Staletic <[email protected]> Co-authored-by: Mickaël Schoentgen <[email protected]> Co-authored-by: Dustin Ingram <[email protected]> Co-authored-by: ysard <[email protected]> Co-authored-by: Lukas Šupienis <[email protected]> Co-authored-by: Lukas Šupienis <[email protected]>
At the moment, the two native events which are emitted when an item is renamed are paired to a single
MovedEvent
by relying on an undocumented behaviour of the File System Events API: two such events will have event IDs which differ only by 1. This may stop working without notice and fails to cover two corner-cases:This PR matches native event pairs by inode instead. This is achieved by actively recording not only the path but also the inode for all events in the extension module. Such extended information is provided when creating the FSEventsStream with the
kFSEventStreamCreateFlagUseExtendedData
andkFSEventStreamCreateFlagUseCFTypes
flags. This requires dealing CFTypes instead of ctypes in the extension module.Other changes in this PR: