Opam itself implements decent locking-- I've never managed to create a broken switch by interrupting it and it catches ctrl-c's and shuts down quickly but gracefully.
This leaves our clone creation and deletion as routines that can corrupt switches if they are interrupted.
Clone creation places a dirtyflag which prevents the switch from being used and causes the broken switch to be deleted when autoswitchmanager finds it.
Since shutil.rmtree doesn't have an ignore argument and it's probably not a safe idea to reimplement safe symlink logic, we can't use the dirtyflag-- it might get deleted first without reimplementing a portion of rmtree's logic. Instead, we just delete the switch's environment file first. Switch deletion is much faster than switch creation, so it is much less likely to be interrupted, but if it is, then the partially deleted switch will not have an environment file, which causes autoswitchmanager to fail to recognize it as a switch during enumeration and ignore it.
These changes passed the existing test cases. I also manually tested that the dirtyflag switches are deleted on startup (watch "find -maxdepth 2 ~/.opam | grep dirtyflag" or similar) and watched dirtyflags get added and deleted in the course of extraction mining. I did no manual testing of the deletion logic, but it ran successfully during tests. All it does is delete a file first, so if the file it deleted didn't exist it would have thrown an error in the course of testing.
Opam itself implements decent locking-- I've never managed to create a broken switch by interrupting it and it catches ctrl-c's and shuts down quickly but gracefully.
This leaves our clone creation and deletion as routines that can corrupt switches if they are interrupted.
Clone creation places a dirtyflag which prevents the switch from being used and causes the broken switch to be deleted when autoswitchmanager finds it.
Since
shutil.rmtreedoesn't have an ignore argument and it's probably not a safe idea to reimplement safe symlink logic, we can't use the dirtyflag-- it might get deleted first without reimplementing a portion of rmtree's logic. Instead, we just delete the switch's environment file first. Switch deletion is much faster than switch creation, so it is much less likely to be interrupted, but if it is, then the partially deleted switch will not have an environment file, which causes autoswitchmanager to fail to recognize it as a switch during enumeration and ignore it.These changes passed the existing test cases. I also manually tested that the dirtyflag switches are deleted on startup (
watch "find -maxdepth 2 ~/.opam | grep dirtyflag"or similar) and watched dirtyflags get added and deleted in the course of extraction mining. I did no manual testing of the deletion logic, but it ran successfully during tests. All it does is delete a file first, so if the file it deleted didn't exist it would have thrown an error in the course of testing.