Actually I am either doing something wrong or this is somehow inconsistent.
The following configuration for a textfile called /sometest/bla_file
results in 3 events containing the file content without any sourcetype assigned.
(no overlappings as far as I know )
(Might this from the docs still be true and in effect here ?
> Important: If you are forwarding data,
> and you want to assign a source type
> for a source, you must do this in
> props.conf on the forwarder. If you do
> it in props.conf on the receiver, the
> override will not take effect
Indexer props.conf (inputs.conf does not contain ANY stanza related to the path or sourcetype)
The fschange input is deprecated in version 5. The text mentions inconsistent behavior. Emphasis below is mine.
First, it does not run predictably on all platforms. Since it has been that way for some time, many felt that was a form of 'implicit' deprecation. We prefer to be open whenever possible, so we decided the time had come to signal that this feature had too many caveats.
Second, it does not do what is generally required for audit use cases, which is track the user/account making the change. Most OS/FS pairs provide high quality, out-of-the-box tools to do this already. In fact our guidance has been to use those tools in most cases, leaving little room for a Splunk-maintained feature.