Samuel Thibault <samuel.thiba...@gnu.org> writes: > Joshua Branson, le ven. 25 oct. 2024 22:28:30 -0400, a ecrit: >> - ftpfs doesn't work so well without internet (obviously) >> - settrans -c \~/hurd-iso /hurd/iso9660fs >> $HOME/ftp://ftp.someftpserver.org/img.iso >> - Often times I will be working offline editing the wiki, and I will >> type `ls ~/`, which will take one minute to list the directory >> contents. > > Ah, that'd probably the TCP connection timeout delay indeed. It'd be > the same with a faulty nfs mount on linux for instance. Having your > mounts directly in your home will always get such concerns, better make > yourself a ~/net directory.
I'll modify the ftp/nfs translator examples on the wiki from: ~/ftp -> ~/net/ftp That way new users won't fit this oddity. >> C-c, works but really slowly (30 second lag). > > Ftpfs should be taught the interrupt_operation protocol for C-c to be > immediate. I'll add it to the small hack entries. >> It would >> be nice if during ftpfs startup, it could check if the Hurd has an >> active internet connection. If the IP address is 0.0.0.0 maybe >> that means no internet? > > That completely depends on the situation you have. > > If your network is really down (no route to the Internet), you'll get > an immediate "Network is unreachable" error. If your network is not This is not the case. Sometimes I work on the Hurd wiki without an internet connection. There is no ethernet cord plugged in, and I have never used (or tried to use the T43's wifi). If you run the Hurd, with no route to internet, and try this: $ cd ~/ $ settrans -c ftp: /hurd/hostmux /hurd/ftpfs / $ cd ftp://ftp.gnu.org/ $ ls The ls command will sit there any do nothing for 1 minute or longer. I just tested this now in real hardware. C-c worked, but took 30 or so seconds. > actually down (pfinet has an IP and a route, packets just don't get > answers), there is no real possibility for pfinet to know it but losing > patience after some timeout. > > Samuel > -- Joshua Branson Sent from the Hurd
