Tobias Weber answers, on that same thread of the mailing list:

"No. It's very simple. Opinions on this are divided, but the fact is that most software doesn't change files, it creates a new one and moves it over the old one. So the file you selected ceases to exist, and therefore gets deselected. It doesn't matter that right after that another file with the same name appears."

I think the point is that nobody expects a filechooser, which the user interacts with to browse _paths_, and which returns again a _path_, to drop that level of abstraction, by memorizing internally some lower level file descriptors.

So while I could have in principle agreed for what concerns a call to "get_file", a call to "get_filename" should simply return the filename which the user has chosen.

_And in any case_, it shouldn't return some other random file, and I think that's what currently happens. So if what I say above is just crazy because the filechooser _has good reasons_ keep a GFile (?) instance internally, at least it should come back to the "unselected" state when that file "disappears".

(In reply to comment #1)
> It doesn't matter that right after that another file with the same name
> appears."

I don't disagree with that (although I wasn't aware of that underlying behaviour). But the "just pick another arbitrary file" behaviour that is definitely unexpected.

If it's interesting, here's my use case. I have a UI where a user selects a hex file resulting from the compilation of some firmware. The firmware could be frequently recompiled as part of the normal workflow. So it needs to be reloaded (because another part of the UI shows a checksum generated from the file). I had a refresh button that would reload the file, but it kept getting the wrong file.

Clearly the solution is to simply get the path when the 'file-set' signal is emitted and store it in my code (instead of getting it on demand from the widget itself).

(Actually, I would have been happy if the docs simply said — loudly — "this widget makes no guarantees that the path you get when it emits the 'file-set' signal will remain the same later.")

> _And in any case_, it shouldn't return some other random file, and I think
> that's what currently happens. So if what I say above is just crazy because the
> filechooser _has good reasons_ keep a GFile (?) instance internally, at least
> it should come back to the "unselected" state when that file "disappears".

Well... maybe. It doesn't have to go "unselected," you could say that the programmer should deal with the usual problems that might crop up in later code if the file is missing. I mean, the file could go missing between the user choosing the file and the code doing something with it.

IMO, ideally, the path would stay the same. The file chooser button is a user activated widget, and should not change state because of external forces that the user might not have control over (or does, but indirectly).

I'm almost certain that if this is bug-worthy then this is a gtk+ problem.

pygtk is not under active development anymore and had its last code changes
in 2013. Its codebase has been archived:
https://gitlab.gnome.org/Archive/pygtk/commits/master

PyGObject at https://gitlab.gnome.org/GNOME/pygobject is its successor. See https://pygobject.readthedocs.io/en/latest/guide/porting.html for porting info.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent version of PyGObject. Thanks!