summaryrefslogtreecommitdiff
path: root/Utility/INotify.hs
Commit message (Collapse)AuthorAge
* catch does not exist error when adding a watchGravatar Joey Hess2013-07-17
| | | | | This could be thrown due to eg, the directory being moved or deleted, so the error should not be propigated.
* assistant: Fix bug that prevented adding files written by gnucash, and more ↵Gravatar Joey Hess2013-06-26
| | | | generally support adding hard links to files. However, other operations on hard links are still unsupported.
* whups, I didn't mean to commit this, it was in to more quickly test out of ↵Gravatar Joey Hess2013-04-24
| | | | limit behavior
* improve display of multiline messages in alertsGravatar Joey Hess2013-04-24
| | | | | | | | This better handles error messages formatted for console display, by adding a <br> after each line. Hmm, I wonder if it'd be worth pulling in a markdown formatter, and running the messages through it?
* let's put type modules under the parent module, not in a Types directoryGravatar Joey Hess2013-03-10
|
* finished where indentation changesGravatar Joey Hess2012-12-13
|
* look for sysctl in some common sbin locations when it's not in PATHGravatar Joey Hess2012-10-06
|
* watch for changes to transfer info files, to update progress bars on uploadGravatar Joey Hess2012-09-20
| | | | | | | | | | | | | | This is handled differently for inotify, which can track modifications of existing files, and kqueue, which cannot (TTBOMK). On the inotify side, the TransferWatcher just waits for the file to be updated and reads the new bytesComplete. On the kqueue side, the TransferPoller has to re-read the file every update (currently 0.5 seconds, might need to increase that). I did think about working around kqueue's limitations by somehow creating a new file each time the size changed. But cleaning up all the files that would result seemed difficult. And really, this is not a lot worse than the TransferWatcher's behavior for downloads, which stats a file every 0.5 seconds. As long as the OS has decent file caching behavior..
* better readProcessGravatar Joey Hess2012-07-19
|
* add back debug loggingGravatar Joey Hess2012-07-19
| | | | | | | | | | | | | Make Utility.Process wrap the parts of System.Process that I use, and add debug logging to them. Also wrote some higher-level code that allows running an action with handles to a processes stdin or stdout (or both), and checking its exit status, all in a single function call. As a bonus, the debug logging now indicates whether the process is being run to read from it, feed it data, chat with it (writing and reading), or just call it for its side effect.
* switch from System.Cmd.Utils to System.ProcessGravatar Joey Hess2012-07-18
| | | | | | | | | | | | | | | | | | Test suite now passes with -threaded! I traced back all the hangs with -threaded to System.Cmd.Utils. It seems it's just crappy/unsafe/outdated, and should not be used. System.Process seems to be the cool new thing, so converted all the code to use it instead. In the process, --debug stopped printing commands it runs. I may try to bring that back later. Note that even SafeSystem was switched to use System.Process. Since that was a modified version of code from System.Cmd.Utils, it needed to be converted too. I also got rid of nearly all calls to forkProcess, and all calls to executeFile, which I'm also doubtful about working well with -threaded.
* lifted out the kqueue and inotify to a generic DirWatcher interfaceGravatar Joey Hess2012-06-18
Kqueue code for dispatching events is not tested and probably doesn't build.