"No such file or directory" when browsing alexschroeder.ch #17

New Issue

asdf · 2019-05-22T06:23:10Z

asdf commented

2019-05-22 06:23:10 +00:00

When attempting to browse phlog entries on alexschroeder.ch I get the following message:

open /home/username/Downloads/menu: no such file or directory

I cannot reproduce the issue in Lynx or the gopher
client, and can view the entries normally when using those applications.

The steps to reproduce are run bombadillo, enter :alexschroeder.ch, and then enter :1 or one of the other link numbers.

I think there are two issues: .bombadillo.ini is probably created automatically, and has savelocation=/home/username/Downloads set but the directory does not exist in my home directory. When this directory is created, the link is not viewed but is saved to that directory (bombadillo is interpreting them as non-text?).

When attempting to browse phlog entries on alexschroeder.ch I get the following message: `open /home/username/Downloads/menu: no such file or directory` I cannot reproduce the issue in Lynx or the gopher client, and can view the entries normally when using those applications. The steps to reproduce are run `bombadillo`, enter `:alexschroeder.ch`, and then enter `:1` or one of the other link numbers. I think there are two issues: `.bombadillo.ini` is probably created automatically, and has `savelocation=/home/username/Downloads` set but the directory does not exist in my home directory. When this directory is created, the link is not viewed but is saved to that directory (bombadillo is interpreting them as non-text?).

sloum commented

2019-05-22 18:45:00 +00:00

Looking into the issue (thank you for the solid reproduction steps), it seems like it is trying to download the file...which is weird since it is a type 1 link. This issue is compounded by the default download location not existing.

I think my proposed solution is two parts:

Update the default download location to just be a users home folder. That should almost certainly exist and issues of folders needing to be created should not occur. A user can update that path as they see fit. That should solve the download error.
I need to do some more research to see what it is about these gophermaps that makes it think that the files should be downloaded. Looking at them I cannot see any reason there would be an issue...

I'll try to update the first item tonight, and I'll start researching the other issue. I did check stubb, my other terminal based gopher client, to see what it did... and it displayed everything corectly.

Just in case it becomes useful for debugging, do you know what gopher server is serving the files? I notice that menu is used rather than the more common gophermap. This certainly should not be a problem; if it is it definitely needs to get fixed.

Looking into the issue (thank you for the solid reproduction steps), it seems like it is trying to download the file...which is weird since it is a type 1 link. This issue is compounded by the default download location not existing. I think my proposed solution is two parts: 1) Update the default download location to just be a users home folder. That should almost certainly exist and issues of folders needing to be created should not occur. A user can update that path as they see fit. That should solve the download error. 2) I need to do some more research to see what it is about these gophermaps that makes it think that the files should be downloaded. Looking at them I cannot see any reason there would be an issue... I'll try to update the first item tonight, and I'll start researching the other issue. I did check `stubb`, my other terminal based gopher client, to see what it did... and it displayed everything corectly. Just in case it becomes useful for debugging, do you know what gopher server is serving the files? I notice that `menu` is used rather than the more common `gophermap`. This certainly should not be a problem; if it is it definitely needs to get fixed.

sloum added the

bug

label 2019-05-22 18:50:52 +00:00

sloum self-assigned this 2019-05-22 18:50:58 +00:00

sloum commented

2019-05-22 19:09:31 +00:00

This seems to be the same issue I have had on other projects with gopher.conman.org. It has to do with the resource selector of your (and their) gophermaps not starting with a /.

I am tempted to just add the slash. The server responds properly if I manually add it. However, there is a point that that is not technically the link as provided. I'll think on it and see which way would be best to go.

I'll update here once it is fixed :)

This seems to be the same issue I have had on other projects with `gopher.conman.org`. It has to do with the resource selector of your (and their) gophermaps not starting with a `/`. I am tempted to just add the slash. The server responds properly if I manually add it. However, there is a point that that is not technically the link as provided. I'll think on it and see which way would be best to go. I'll update here once it is fixed :)

sloum commented

2019-05-23 02:23:36 +00:00

Closed by #18

Solved the issue. The regex defining the parts of a gopher url was not set up to allow a situation in which a slash does not follow the gopher type. This has been resolved. The default save path has also been updated to a user's home directory. If any user seeing this already has a .bombadillo.ini file in their home directory they can delete it and it will be correctly rebuilt if they do not need any other settings in it. If they want to preserve settings, a user can delete the savelocation row from the ini file, or manually reset the save location by running :set savelocation [path to prefered save location] in Bombadillo.

If any further issues are found around this, please open a new issue. Otherwise: enjoy Bombadillo! :)

Closed by https://tildegit.org/sloum/bombadillo/pulls/18 Solved the issue. The regex defining the parts of a gopher url was not set up to allow a situation in which a slash does not follow the gopher type. This has been resolved. The default save path has also been updated to a user's home directory. If any user seeing this already has a .bombadillo.ini file in their home directory they can delete it and it will be correctly rebuilt if they do not need any other settings in it. If they want to preserve settings, a user can delete the `savelocation` row from the ini file, or manually reset the save location by running :`set savelocation [path to prefered save location]` in Bombadillo. If any further issues are found around this, please open a new issue. Otherwise: enjoy Bombadillo! :)

sloum closed this issue

2019-05-23 02:23:36 +00:00

Sign in to join this conversation.