This shouldn't be needed, as according to the Linux inotify(7) man page,
the entries are supposed to be aligned. It looks like libinotify-kqueue
doesn't respect this and doesn't properly zero-pad the name field.
287c77c...
by
Andrei Alexeyev <email address hidden>
filewatch_inotify: fix compilation with libinotify-kqueue
d2c01b8...
by
Andrei Alexeyev <email address hidden>
dynstage: don't destroy library filewatch on deletion
c668267...
by
Andrei Alexeyev <email address hidden>
log: sync outputs before shutdown or crash
Previously this half-worked: fflush() was called on log_fatal, but not
in case of assertion failure, leaving the on-disk log truncated.
1191b23...
by
Andrei Alexeyev <email address hidden>
util/io: add SDL_RWsync function
This function is meant to flush any internal buffers and (hopefully)
ensure the data has reached its ultimate destination (e.g. a file on
disk) before returning. This is currently implemented as a crude hack
and only supports stdio-based RWops. It calls fflush() on the internal
FILE* pointer, and on POSIX-systems it also calls fsync() on the file
descriptor.
b9fb068...
by
Andrei Alexeyev <email address hidden>
filewatch: rewrite inotify backend
It's now based on directory monitoring, which is more complicated, but
also much more reliable, especially when dealing with move events and
hard links. It is also closer to the semantics we actually want
(monitoring fs paths for changes, not inodes). It will still get
confused if the directory itself gets moved (directly or indirectly),
though, but handling that correctly is absurdly difficult and not
important for our use-case.
Importantly, FileWatch no longer becomes useless after reporting a
FILEWATCH_FILE_DELETED event: if another file is placed onto the same
path later, the FileWatch will report FILEWATCH_FILE_UPDATED. Some
client logic can be simplified because of that.
69ea82d...
by
Andrei Alexeyev <email address hidden>
util/stringops: add memrchr() polyfill
057f3f5...
by
Andrei Alexeyev <email address hidden>
util/stringops: prefer strtok_r from libc
00dca36...
by
Andrei Alexeyev <email address hidden>
