Closed n-st closed 5 years ago
This could be implemented as last thing to do in the FUSEView.init method. This would still be before the mount actually becomes active, but waiting for 1 second or using a blocking ls /
should be able to fix that. Nonetheless, that would need some testing regarding timing and edge-cases e.g. when the FUSE driver is shutting down right after having been started.
There are multiple methods for checking for mountpointiness of directories, the best of them is probably the mountpoint
utility, which also issues a potentially blocking stat
call. So checking whether the mount is actually available right after the callback should be no problem.
I have a somewhat bad feeling about starting an arbitrary program from within the driver, as this also leads to a lot of security, exception and subprocess handling issues. Would another notification channel also be ok? Busy checking for file / port availability is obviously no perfect solution. Sending a notification via D-Bus would also not present a generic solution, but might be helpful later when it comes to writing an integrated GUI. Another possibility could be tail
ing the system log and blockingly searching for the respective startup log message, which would also be possible right now without modifications to any studip-fuse code. If you really want an even simpler solution we could also write to a specific normal file on startup (i.e. echo "started" > /tmp/studip-fuse-%PID.txt
) so that you can just use a blocking read-line to wait for the startup.
Enhancement: Add an option to run a command when
studip-fuse
succeeds in mounting.This would allow the user to correctly automate mounting the FUSE,
rsync
ing files to local storage, and unmounting the FUSE afterwards.