On Wed, Jul 17, 2019 at 11:03 AM Noam Postavsky <npostavs@gmail.com> wrote:

> Ken Manheimer <ken.manheimer@gmail.com> writes:
>
> > The problem is that this provision sometimes registers buffers that
> > were present in the editing session before the pdbtracking session, so
> > that pdbtracking sometimes causes pdbtracked buffers to be deleted
> > when it shouldn't.
> >
> > I'm unsure what exact conditions lead to the problem,
>
> I guess this can happen if your python source files are accessible
> through symlinks?
>

Yes, that turned out to be the situation in the cases I encountered. There
are probably other ways a file can be found via multiple paths, like
hardlinks and multiple mounts of a filesystem.

> but I'm pretty sure
> > that `python-pdbtrack-set-tracked-buffer()` uses the wrong buffer-finding
> > function. Instead of using `get-file-buffer()`, it should be using
> > `find-buffer-visiting()`. I believe that this will solve the problem.
>
> I think this should be conditional on (or find-file-existing-other-name
> find-file-visit-truename), which is what find-file-noselect checks for.
>

No, as far as I can tell, that doesn't hold in this situation.

The point of this issue is to not delete a source file that was already
present in the editing session before the pdb-tracking debugging process
stepped through code in the file. The prior presence of the file should be
respected regardless of the settings of find-file-existing-other-name or
find-file-visit-truename, so these settings should not be considered for
this comparison.

Ken