-1 from me.  I will leave it open for another guy to close it though.

(1) Log and backup files should not be hidden for at least two reasons:
(1.1) They are useful.
(1.2) They contain sensitive data.
(2) There is a configuration parameter for the number of days to keep those files.  If you do not like them, you can even disable them by using 0.
(3) What usability issues do you see?  Typically I do not edit more than 2 or 3 files semi-simultaneously, so they all appear in my history.  If I keep one file in one directory, the main file is always listed first.

You can set the number of days backup and log files are kept.
If you don't like how many it's saving, change that setting to "1"

This is not a bug.  Thanks.

reopening: gnucash could could at least give the option to save backups to ~/.gnucash/backups instead

The usability issue is quite clearly clutter.  My computer has not only gnucash files and gnucash is not the only program I use.  I think the usability issue (for the computer, not necessarily for gnucash itself) should be obvious.  It is the same issue as a cluttered desk.

reassigning to myself, I guess neither will Andi nor Derek will want to work on it.

"too many options" is a BAD THING.
Why does this need to be implemented?
Why is it more important than fixing lots of the other real bugs that exist?

All it does is hide the storage instead of removing it, making users even less aware that their data is being copied..  And it gives a potential attacker yet another vector to steal personal data because they could cause gnucash to store backups somewhere the attacker controls.

I made no claims as to the relative importance of this bug.  Furthermore, if there is a security problem, then this is not going to worsen that.  Is there is a need to discuss how to try and fix this, then let's discuss.

I'm afraid you're wrong, adding this feature WOULD add a security issue that does not exist currently.  Right now GnuCash only writes back into the directory where the datafile already exists, which is already controlled by the user.  By adding an option to control where those go you're opening up an attack to cause gnucash to potentially write data files to a place NOT controlled by the user.

So again I think this request should be closed as "not a bug", because it's just not a bug.  It's working as designed.

Fuck Ack.
I have seen that you also track this one launchpad as well, so let us close it as NOTABUG and leave it that way :-)

(In reply to comment #8)
> Fuck Ack.
Ouch.  This was *not* intended.
s/Fu../Full/, please

Unless I don't understand some aspects of this bug, I would say that how gnucash currently works and how Rolf suggest it to work can both be used!

The problem with Rolf suggestion is that backup files always go to ~/.gnucash/backups, but this is not necessary. We can still keep gnucash data file *and* "gnucash backups" directory where the user decided to put the gnucash data file. 

This way, the user would still completely control his data files, and it would be cleaner and easier to manage for the final user than huge amount of individual files mixed with the main file.

What do you think about this suggestion?

Even if you don't decide to implement this specific solution, I persist to think that having continuously increasing number of files in gnucash folder is a usability problem that can be worked on (but not the most high priority bug ;) ).

It's not a continuously increasing number of files.  It's based SOLELY on how many times you save your data file within the backup time period you have specified.  If you change that setting to a lower number GnuCash will keep fewer backup files.

Oh! I didn't even know that gnucash worked that way, great! Please ignore my comment and thanks for these informations :) .

(In reply to comment #8)
> I have seen that you also track this one launchpad as well, so let us close it
> as NOTABUG and leave it that way :-)

I was afraid of that reaction and thus opened a ticket at a place where usability is usually of higher concern.  Just to make sure it remains on the radar.

Increasing number or not, tens or even hundreds of files is a nuisance and hinders usability.  Having gnucash save backup files automatically for a few days is a good thing and the numbers get large easily when you autosave every 10 minutes or so which is also a good thing.

BTW, since there seems to be some concern about users actually recognizing the backup files as such (FWIW, *I* never thought they were *complete* backup files but rather some kind of log or diff), I suggest to actually rename them to *.bkp or *.bak.

I am not complaining, but I think one has to scour through the not so well-structured docs too often which when it occurs might hint at a bad usability choice.  No offense meant, I am trying to make gnucash better with concrete suggestions.

It's in the docs.  It's in the FAQ.  If someone has a question there are many ways to look up the answer.

Thanks, Derek for proving my point exactly

"I think one has to scour through the not so well-structured docs too often which when it occurs might hint at a bad usability choice."

+1 for bak or bkp from me.  small step, but even that counts.

Now you're putting incorrect words in my mouth.  I think the GnuCash documentation is extremely well written and very well organized.  Moreover, I think the FAQ is pretty well organized, too.  For a question of "what does .xac mean", I think its PERFECTLY reasonable to have to look that up!   The average user never even notices the backups in the first place because gnucash auto-opens the file.

I don't object to .bak, however then you lose the knowledge that it's a GNUCASH backup datafile.

Also, I suspect that this will all be moot once we swap over to SQL as the default.  We wont have .xac backups (only .log files).

(In reply to comment #17)
> Now you're putting incorrect words in my mouth.

I didn't intend to and I wasn't.  I was not referring to whether or not the docs are in good shape.  The point you helped me make was that one even has to consult the docs.  With .bak, the file's contents and purpose is obvious and you don't need to even grow the desire of "gee, I wonder what those files really are, let's look that up".

> I don't object to .bak, however then you lose the knowledge that it's a GNUCASH
> backup datafile.

OK, let's do it, then.  

The point you raise could be addressed by having the files named $origfilename-$date.gnucash.bak or somthing like that.  Although I guess that $origfilename will usually give that away, too.

> Also, I suspect that this will all be moot once we swap over to SQL as the
> default.  We wont have .xac backups (only .log files).

Possibly, and I am looking very forward to it.  But nobody really knows if it's weeks, months or years we are talking about until that happens.

*** Bug 542227 has been marked as a duplicate of this bug. ***

*** Bug 542227 has been marked as a duplicate of this bug. ***

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=537605. Please update any external references or bookmarks.