Hi Karl,

I'm happy to submit a patch with the issue.

I have not read deeply into the framework API's, but I tested a simple "hack" to pass to the StringBuffer constructor and it worked:

  StringBuffer path = new StringBuffer(outputDescription.substring(0, outputDescription.length() - 1));

Obviously, the patch should include precondition checks on the outputDescription length etc.

Is this an appropriate use of the "outputDescription" argument to removeDocument() or can you suggest more reliable way to obtain the root directory? (e.g. derived some how  from the Job or FileOutputConfig)

Thanks,

  //david

On Tue, 2017-10-31 at 12:55 -0400, Karl Wright wrote:

*** EXTERNAL email. Please be cautious and evaluate before you click on links, open attachments, or provide credentials. ***
Hi David,
This is not the expected behavior.  The removeDocument() method should be looking for the existence of the root directory, and returning if that doesn't exist, before attempting to remove the specified document.
Please create a ticket, and if you are interested, create a patch.  Thanks!
Karl

On Tue, Oct 31, 2017 at 11:57 AM, Hotchkiss, David <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:
Using ManifoldCF v 2.8.1: I think there is a problem with the Filesystem
Output Connector's removeDocument method.

During testing, we noticed that documents removed from the source
repository did not result in a zero-length file in the file system
destination.

When the "removeDocument()" method checks for existence of the root, it
constructs a "File" object from an empty StringBuffer instead of the
root path for the output destination.  This causes removeDocument to
return on condition that the path does not exist.

Is this the expected behavior?

Thanks,

  //david
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB