[Bug: 21.4.21] dired complains about an unrelated directory

[Stephen J. Turnbull]

Michael Sperber writes:

 > > /export/kupfer/tonic/stevel/ is the directory I want to visit.
 > > /net/sfwnv/export/nv/ is an NFS directory that I had tried to visit
 > > earlier in the day but couldn't (permissions problem).
 > >
 > > I haven't looked at the relevant dired code, but I'm hypothesizing that
 > > it's trying to reclaim resources associated with the directory I
 > > couldn't visit.  The buffer for that directory has this text:
 > >
 > >   /net/sfwnv/export/nv:
 > >   ls: error reading directory /net/sfwnv/export/nv/.: Permission denied
 > >   total 0
 > >
 > > Let's try killing that buffer...  done.  And now dired lets me visit
 > > /export/kupfer/tonic/stevel/.
 > 
 > It's trying to see if it can re-use the earlier buffer for the new dired
 > command you're doing, and, in the process of that, tries to find the
 > truename of the directory of that earlier buffer.

If it can't read the directory in the dired buffer, then you can
assume that you can't match it to the current request and move on, or
you can assume it's now useless, nuke the association with the former
directory, and reuse it.  I think the latter is excessively aggressive
(it destroys the buffered information about the directory in case of a
change in accessibility since the directory was last accessed).

 > You can set `find-file-compare-truenames' and
 > `dired-find-file-compare-truenames' to nil to prevent it from doing
 > that.

Shouldn't be necessary in this case, unless I'm missing something.
Wrap the test in a condition case that fails safe (ie, creates a new
dired buffer).