Re: bin/47577: Mail(1)/mail(1)/mailx(1) gets stuck when current folder becomes accessible

[Steffen "Daode" Nurpmeso <sdaoden%gmail.com@localhost>]

The following reply was made to PR bin/47577; it has been noted by GNATS.

From: Steffen "Daode" Nurpmeso <sdaoden%gmail.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
sdaoden%gmail.com@localhost
Subject: Re: bin/47577: Mail(1)/mail(1)/mailx(1) gets stuck when current
 folder becomes accessible
Date: Mon, 18 Feb 2013 19:19:07 +0100

 christos%zoulas.com@localhost (Christos Zoulas) wrote:
  | On Feb 18,  2:25pm, sdaoden%gmail.com@localhost 
(sdaoden%gmail.com@localhost) wrote:
  | -- Subject: bin/47577: Mail(1)/mail(1)/mailx(1) gets stuck when current =
 \
  |folde
  |=20
  || If you open a folder with a relative path, use the cd command to change=
  \
  |  the current working directory, then any action that needs to update the=
  \
  |  opened folder (as opposed to the temporary MBOX; e.g., switching to a \
  |  different folder) will fail and claim that the opened folder is not \
  |  accessible.
  || You need to cd to a path which turns the relative folder path accessibl=
 e \
  |  again to be able to continue.
  || This is just one facet of a basic architectural problem of Berkeley Mai=
 l, \
  |  i.e., concurrent deletion of the current folder etc. still bails, but f=
 or \
  |  this particular aspect the solution is easy.
  |=20
  | I think it is better to canonicalize the name when the name is set? No?
 
 Sure; "fi" etc. then always show an absolute path, which is often
 annoying imho, especially on 80 column terminals, though.
 I as a user would then really like to see some
 "/path1/[...]/folder" instead of "p1/p2/p3/p4/folder".  I, e.g.,
 often have problems with mksh(1) because that radically cuts job
 paths at 40 (or so) characters, so that i sometimes have to check
 ps(1) to know which job relates to what command.
 
 So then i would possibly consider a basename(3)/realpath(3) tuple
 (or, better, a path and an offset) from the begin on, the one for
 display and the other for file operations.
 
 Possibly overkill; I think even then i would delay the realpath(3)
 until this very command is used, because (1) it is very expensive
 (not that expensive with a getcwd() syscall, but still), and (2)
 it is completely useless unless the cd command is used.  I've just
 encountered the problem that the Berkeley codebase stucks
 completely unless the open folder comes into sight again, and that
 was an at-a-glance solution for this particular problem, which
 works automatically and without user interaction.
 
 I haven't considered yet the basename(3)/realpath(3) solution;
 hmmm; i think i look into that tomorrow, and come back with an
 alternative patch if it's easy to implement -- i couldn't tell how
 many places would need to be changed right now.
 
  | christos
 
 --steffen