Inconsistent fschange behaviour ?

[flo_cognosec]

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

)

Why ?

Indexer props.conf (inputs.conf does not contain ANY stanza related to the path or sourcetype)

[source::/sometest/...]
BREAK_ONLY_BEFORE_DATE=false
BREAK_ONLY_BEFORE=goblygook
LEARN_MODEL = false
LEARN_SOURCETYPE = false
sourcetype=bla_indexer

UF inputs.conf

[fschange:/sometest]
index=some_index
followLinks=false
recurse=true
pollPeriod=60
hashMaxSize=100000000
fullEvent=true
sourcetype = some_test

props.conf

[source::/sometest/...]
LEARN_MODEL = false
LEARN_SOURCETYPE = false

[I_am_Jeff · Accepted solution]

Refer to this link.

http://splunk-base.splunk.com/answers/63874/why-is-fschange-a-deprecated-feature-in-splunk-50

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.