<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Inconsistent fschange behaviour ? in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Inconsistent-fschange-behaviour/m-p/89731#M18622</link>
    <description>&lt;P&gt;Actually I am either doing something wrong or this is somehow inconsistent.&lt;BR /&gt;
The following configuration for a textfile called /sometest/bla_file &lt;BR /&gt;
results in 3 events containing the file content without any sourcetype assigned. &lt;BR /&gt;
(no overlappings as far as I know )&lt;BR /&gt;
(Might this from the docs still be true and in effect here ? &lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;&amp;gt; Important: If you are forwarding data,
&amp;gt; and you want to assign a source type
&amp;gt; for a source, you must do this in
&amp;gt; props.conf on the forwarder. If you do
&amp;gt; it in props.conf on the receiver, the
&amp;gt; override will not take effect
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;)&lt;/P&gt;

&lt;P&gt;Why ?&lt;/P&gt;

&lt;P&gt;Indexer props.conf (inputs.conf does not contain ANY stanza related to the path or sourcetype)&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[source::/sometest/...]
BREAK_ONLY_BEFORE_DATE=false
BREAK_ONLY_BEFORE=goblygook
LEARN_MODEL = false
LEARN_SOURCETYPE = false
sourcetype=bla_indexer
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;UF  inputs.conf &lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[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
&lt;/CODE&gt;&lt;/PRE&gt;</description>
    <pubDate>Wed, 16 Jan 2013 16:53:13 GMT</pubDate>
    <dc:creator>flo_cognosec</dc:creator>
    <dc:date>2013-01-16T16:53:13Z</dc:date>
    <item>
      <title>Inconsistent fschange behaviour ?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Inconsistent-fschange-behaviour/m-p/89731#M18622</link>
      <description>&lt;P&gt;Actually I am either doing something wrong or this is somehow inconsistent.&lt;BR /&gt;
The following configuration for a textfile called /sometest/bla_file &lt;BR /&gt;
results in 3 events containing the file content without any sourcetype assigned. &lt;BR /&gt;
(no overlappings as far as I know )&lt;BR /&gt;
(Might this from the docs still be true and in effect here ? &lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;&amp;gt; Important: If you are forwarding data,
&amp;gt; and you want to assign a source type
&amp;gt; for a source, you must do this in
&amp;gt; props.conf on the forwarder. If you do
&amp;gt; it in props.conf on the receiver, the
&amp;gt; override will not take effect
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;)&lt;/P&gt;

&lt;P&gt;Why ?&lt;/P&gt;

&lt;P&gt;Indexer props.conf (inputs.conf does not contain ANY stanza related to the path or sourcetype)&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[source::/sometest/...]
BREAK_ONLY_BEFORE_DATE=false
BREAK_ONLY_BEFORE=goblygook
LEARN_MODEL = false
LEARN_SOURCETYPE = false
sourcetype=bla_indexer
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;UF  inputs.conf &lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[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
&lt;/CODE&gt;&lt;/PRE&gt;</description>
      <pubDate>Wed, 16 Jan 2013 16:53:13 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Inconsistent-fschange-behaviour/m-p/89731#M18622</guid>
      <dc:creator>flo_cognosec</dc:creator>
      <dc:date>2013-01-16T16:53:13Z</dc:date>
    </item>
    <item>
      <title>Re: Inconsistent fschange behaviour ?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Inconsistent-fschange-behaviour/m-p/89732#M18623</link>
      <description>&lt;P&gt;Refer to this link.&lt;BR /&gt;&lt;BR /&gt;
&lt;A href="http://splunk-base.splunk.com/answers/63874/why-is-fschange-a-deprecated-feature-in-splunk-50"&gt;http://splunk-base.splunk.com/answers/63874/why-is-fschange-a-deprecated-feature-in-splunk-50&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;The fschange input is deprecated in version 5.  The text mentions inconsistent behavior.  &lt;STRONG&gt;&lt;EM&gt;Emphasis below is mine.&lt;/EM&gt;&lt;/STRONG&gt;&lt;/P&gt;

&lt;HR /&gt;

&lt;P&gt;First, &lt;STRONG&gt;&lt;EM&gt;it does not run predictably on all platforms&lt;/EM&gt;&lt;/STRONG&gt;. 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. &lt;/P&gt;

&lt;P&gt;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. &lt;/P&gt;</description>
      <pubDate>Thu, 14 Feb 2013 20:53:59 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Inconsistent-fschange-behaviour/m-p/89732#M18623</guid>
      <dc:creator>I_am_Jeff</dc:creator>
      <dc:date>2013-02-14T20:53:59Z</dc:date>
    </item>
  </channel>
</rss>

