joe42
commented
10 years ago Hi callegar,
The way cloudfusion is started is a result of a storage system of similar components I developed, where cloudfusion is one of the components. The complete system does have a configuration gui though. I can see that it feels strange to use it this way, as it is neither similar to unix tools, nor to graphical interfaces. I decided to go this way because first you are able to use several accounts (i.e. dropbox and sugarsync). Second, you can dynamically reconfigure parameters during runtime. I think you made a good point and I will see that this is implemented as another way of starting cloudfusion. Actually, fusermount should work. This seems to be an issue with python waiting for processes or threads to stop before the process is stopped. I experienced this problem with a java fuse component, too. I implemented a very brutish way of shutting down the application which is triggered by deleting the config file. I could include it in the start script to stop cloudfusion by calling "cloudfusion configpath stop" or similar.
Thanks, joe
Hi,
very nice project, but the way it is configured, started and stopped seems a bit unusual.
I would like to suggest something like having a config file that is stored in the user home and readable just by him/her and
to start the daemon
and
to stop it.
This is what most fuse filesystems do.
Conversely, the current setup makes starting/stopping the daemon inconvenient since you need two operations to start (starting the daemon proper and copying the config). Then when you stop the daemon you loose the config.
I believe that having an easy way to start/stop the daemon could be quite useful. Many people are on laptops that only have intermittent proper connections and that at times are on mobile plans that get quite expensive if by mistake you start downloading/uploading stuff to dropbox.