[
https://issues.apache.org/jira/browse/FELIX-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed FELIX-5134.
----------------------------------
Resolution: Not A Problem
Assignee: Guillaume Nodet
> Felix Fileinstall does not work correctly with Subdirectories
> -------------------------------------------------------------
>
> Key: FELIX-5134
> URL: https://issues.apache.org/jira/browse/FELIX-5134
> Project: Felix
> Issue Type: Bug
> Components: File Install
> Affects Versions: fileinstall-3.5.0
> Environment: Apache Karaf 4.0.3
> Reporter: Fabian Lange
> Assignee: Guillaume Nodet
> Attachments: Screen Shot 2015-12-13 at 11.27.14.png
>
>
> As started to discuss on mailing list I now have a full functional
> reproduction case using apache karaf.
> Here is how to reproduce:
> download the 4.0.3 distribution of karaf, which contains fileinstall 3.50
> extract it and move `org.apache.felix.fileinstall-deploy.cfg` from `etc` to
> another empty directory outside of karaf (in my case i called it test). The
> reason to move this file is that its a valid config and that it would make it
> harder to spot the problem if it would be actually deployed, but the problem
> is not related to this file.
> Now start karaf in debug mode by calling `karaf debug`, wait for it to
> cleanly start and attach a debugger. Set a Breakpoint to
> `WatcherScanner#L125` the method is called `process()`.
> (note if you need to retry that, be sure to delete the karaf data dir before
> retrying as it messes with state).
> Now move the test directory into your etc directory. you will see the
> breakpoint fire with a situation like the attached screenshot.
> The Scanner saw this file
> `/Users/fabian/Downloads/apache-karaf-4.0.3/etc/test/org.apache.felix.fileinstall-deploy.cfg`
> and called process on it. Because its parent directory is NOT the one
> configured in the config, it now starts to walk up the tree. Here is the
> problem.
> Next check is if "test" has the configured directory as parent, which it has,
> and then the loop exists, leaving the "test" directory as file.
> This is then later passed down the line to config processing, which will
> FAIL, thus keep the directory "test" forever in the retry logic of
> `DirectoryWatcher#processingFailures` and `DirectoryWatcher#doProcess`.
> For me it looks like as if the walking logic could be kept, but if it finds a
> match, the original file needs to be added in `ScannerWatcher#process()` and
> `remove`.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
