The filemon(4) format uses newlines as record separators which while uncommon are perfectly valid inside file paths. This violates the data transparency required to correctly parse filemon(4) output and can be abused to inject arbitrary records into the filemon(4) output.
Simon any ideas on how to fix this and maintain bmake compat?
There is no way an existing user of the filemon(4) API can correctly deal with newlines in paths. As such I would recommend the following changes to maintain compatiblity: * Drop paths incompatible with the current format from the event stream. This keeps existing code working for all paths encodable without violating data transparency. * The simplest solution would be to add an ioctl() switching the encoding to be used before attaching a file descriptor to the filemon file descriptor. It would be enough to just use NUL as separator between records. If records contain multiple NUL terminated string the the consumer would have to deduce the number of string arguments from the first byte of a record unless. But this is kind of encoding would still be a fragile hack and existing code couldn't skip over new record types. Because of this I would recommend fixing this problem in a way to minimize the impact of future changes by migrating the encoding to a stream of djb style netstrings. They are very easy to generate and fairly easy to parse without switching to a binary encoding.
I have no sympathy for newlines in paths, which are invariably a sign of someone trying to break things.... certainly not something that make (main consumer of filemon) is likely to be interested in. So I would agree that ignoring them is the appropriate reaction.
The problem isn't that make's meta mode doesn't work for sane code bases, but that filemon could be very useful for dealing with other kinds of applications as well. Those applications have to support all user provided file names. Yes a user should be smacked over the head for creating file names with new lines, but that isn't valid excuse leave APIs broken. In theory a path can contain all characters except the NUL byte which acts as terminator for C strings. And the forward slash is the only path separator. A file system monitoring API should be able to deal with all legal paths not just some "sane" subset we all like because it lets us get away with sloppy scripts (e.g. assume that file names don't include anything from $IFS, will neither contain neither backticks nor dollar signs, ...).