Sticky state for containers (?) when switching back and forth between the default and virtual file systems
Still working on a good description. Here's a bes command file that shows the error:
The response should be to show the fnoc1 DDS and then two copies of the CSV file's DDS, but instead the second request (of the three) returns fnoc1's DDS.
Is this a fail with the container, the container storage or the definitions?
Is this a real problem - the OLFS never issues requests like this? It seems we see this sticky behavior in a real running server when using the web interface, but I'm not able to reproduce that now
Regarding the previous comment:
Implemented a fix. I added a method to the BESContainerStorageList that searches all of the stores and deletes every instance of a container. This will work with the OLFS, but is not how the BES was really intended to work.
For some reason, the daemon does not work while besstandalone does.
This is a problem that appears to be present on OSX only, or may have to do with the libcurl version. OSX uses:
while Centos 7 (where this code works) uses:
Close this ticket and open a new report.