Resolution: Not A Problem
Affects Version/s: fileinstall-3.5.0
Fix Version/s: None
Component/s: File Install
Environment:Apache Karaf 4.0.3
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`.