Pádraig Brady wrote: > On 12/22/2011 11:48 PM, Pádraig Brady wrote: >> On 12/22/2011 09:50 PM, Alan Curry wrote: >>> Bob Proulx writes: >>>> >>>> Jim Meyering wrote: >>>>> Are there so many new remote file systems coming into use now? >>>>> That are not listed in /usr/include/linux/magic.h? >>>> >>>> The past can always be enumerated. The future is always changing. It >>>> isn't possible to have a complete list of future items. It is only >>>> possible to have a complete list of past items. The future is not yet >>>> written. >>> >>> Between past and future is the present, i.e. the currently running kernel. >>> Shouldn't it return an error when you use an interface that isn't >>> implemented >>> by the underlying filesystem? Why doesn't this happen? >> >> That's a fair point. >> >> Eric shouldn't some/all remote file systems in the kernel >> return ENOTSUP for inotify operations? > > Oh right, as Sven points out, > a notification _is_ sent for local processes modifying a remote file. > I guess we'd need a IN_REMOTE flag (send remote events too), which > remote file systems would return ENOTSUP if they don't support that. > That's getting a bit awkward though.
I'm thinking of recording[*] which file systems are local and which are remote. Then we can make tail -f warn when one or more of its file arguments resides on a remote file system. We may finally have to add and document --disable-inotify. Jim [*] It's easy to record local/remote in a table from which a switch stmt or gperf table is derived, just as is currently done for FS magic numbers.
