Pádraig Brady wrote: > On 12/23/2011 12:08 PM, Jim Meyering wrote: >> 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. > > You mean by tagging the table in stat.c with say "(remote)" after the > hex constant? > Then use that to build a header for use by tail::fremote() ?
Yes. >> 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. > > Currently we fall back to polling for remote file systems. > I'm not sure it's worth warning since it's only a latency difference. My original goal was to warn, for unknown file system types, that the type is unknown (suggesting to report it), and that tail -f is resorting to the use of polling. >> [*] 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.
