A cross-platform file change monitor with multiple backends: Apple OS X File System Events, *BSD kqueue, Solaris/Illumos File Events Notification, Linux inotify, Microsoft Windows and a stat()-based backend.
I've been using FSWatch to trigger actions for tiny files so this has never become an issue, but now I find I'm not sure how it would behave when monitoring a directory with large files being transferred from a slow connection.
The idea is, of course, to trigger once the file is completed. I'm not sure if there's currently any check for this built-in or a parameter to specify it. For large files picking it up multiple times (until it's complete) would be as undesirable as picking the file up halfway and never again.
Wherever I can I've avoided this by using temporary names and renaming upon completion but there's a process now that I can't control in this way and I'm not sure how fswatch will behave.
Does fswatch by default (or by parameter) discriminate between opened files being written and closed files?
(error handling on incorrectly-closed files is a problem of my routine, of course).
Hi
I've been using FSWatch to trigger actions for tiny files so this has never become an issue, but now I find I'm not sure how it would behave when monitoring a directory with large files being transferred from a slow connection.
The idea is, of course, to trigger once the file is completed. I'm not sure if there's currently any check for this built-in or a parameter to specify it. For large files picking it up multiple times (until it's complete) would be as undesirable as picking the file up halfway and never again.
Wherever I can I've avoided this by using temporary names and renaming upon completion but there's a process now that I can't control in this way and I'm not sure how fswatch will behave.
Does fswatch by default (or by parameter) discriminate between opened files being written and closed files?
(error handling on incorrectly-closed files is a problem of my routine, of course).