One of the original design features of the remote filesystems is that they would be able to support an offline mode where files within the cache could be used when the URL is not accessible. This has not been implemented uniformly for all filesystem types and review needs to be done. (This probably will require some sort of proxy to simulate filesystems being down, and I often find myself trying to do this sort of testing when filesystems actually do go down.)
The GitHub/GitLabs filesystem didn't have the timeout set on the first connection to the remote server, and when abbith was down, Bill discovered things would just hang. I've put in a timeout for the initial connection, and the "toString" message will report the offline status.
One of the original design features of the remote filesystems is that they would be able to support an offline mode where files within the cache could be used when the URL is not accessible. This has not been implemented uniformly for all filesystem types and review needs to be done. (This probably will require some sort of proxy to simulate filesystems being down, and I often find myself trying to do this sort of testing when filesystems actually do go down.)
The GitHub/GitLabs filesystem didn't have the timeout set on the first connection to the remote server, and when abbith was down, Bill discovered things would just hang. I've put in a timeout for the initial connection, and the "toString" message will report the offline status.