This issue was reported as Debian Bug #270113 by Johan Renström johan_renstrom@home.se. It is still reproducible with 3.2.6a.
If I, while working on a figure, go to the "open" menu and changes the
directory to directory A to look for another file to open but changes my mind
and press cancel, then xfig seems to change the "current directory" or the
directory associated with the figure and if I then press "save" from the file
menu, xfig writes my current file in the directory where I was last
(directory A). The most anoying is that if that directory contains a file
with the same name then xfig overwrites that file without warning!
An example
Two directorys
~/test/
which contains
test.fig
and
~/test2/
which is empty
start xfig
open ~/test/test.fig from open-menu
go to open-menu and to directory
~/test2/
do nothing but press cancel
press "save" from file-menu
now test.fig is in both ~/test/ and ~/test2
It works almost every time! :)
I am not sure, whether this is a bug or rather a feature. When changing the directory in the "Open" menu, the working directory is immediately updated. Since the file browser displays the files in the current working directory, the immediate change can at least be expected, if it is not even obvious. The "Save" button then uses the current working directory.
Some users might expect the current behavior. In modern UIs, a "Cancel" button would probably cancel all transactions and return the application into the previous state. I opt to put this on a wish list. The question is, whether to keep the ticket open, or set it to "wont-fix".
With the next release, when opening the "Save as..." or "Export" menu, navigating to a different directory and then pressing "Cancel", the save- or export-directory is not changed.
As long as the export-directory is the same as the save-directory, changing the save-directory also changes the export-directory. If, in the "Export"-menu, a different export-directory is chosen, the save- and export directories become independent from each other.
I just tested this with 3.2.7 and the problem still exists exactly in the way it is described in the initial bug report.
In 3.2.7a this is really fixed :-)