Empty Group Gets Deleted When I Wish It Wasn't
Popular easy-to-use and secure password manager
Brought to you by:
ronys
Menu
▾
▴
#1327 Empty Group Gets Deleted When I Wish It Wasn't
When a Group is created, it is empty - as noted by the empty diamond icon (mind you: when making this folder, the diamond was full when I was typing in the name).
The database can be saved with the empty Group, which is great.
If I populate the Group with an entry and then immediately delete that entry, I expect to return to an empty Group. Instead, PasswordSafe 3.38.02 deletes the entry AND the Group.
The following appears relevant to this problem as the symptoms are the same https://sourceforge.net/p/passwordsafe/bugs/414/#e4bc (quite old).
Sorry - I believe that this is working correctly.
As noted in the link you provided (and others), groups do not really exist. It is just a name of a field that is helpful in displaying the item in a Tree Display. It is just like any other text field in the List view.
If you added an entry to an empty group and then performed “Undo” then the empty group would still be there. However, you didn’t do this, you deleted the sole entry in a group and PasswordSafe has no knowledge that it was once an empty group. Once the only entry with that “group” field has been deleted, then it is correct that there is no group displayed in the Tree view. Just think how cluttered the Tree view would be if every time the last entry in a group was deleted, the group was saved in the “Empty Group” list.
Thanks for the Undo tip. I would still prefer an "Explorer-style" behavior where groups, just like folders, need an action actually directed at them before they disappear.
When the database is saved with an empty Group within it, what space does that 'thing' occuppy? I read carefully the explanation and I am still confused as to why "empty Groups do not exist" yet the database can save them. ALL Groups were once an empty group, so I would think keeping the empty group to be a more consistent behavior, and I have no concern at all for cluttering.
Last edit: Mark G. 2016-02-21
I must repeat, “groups” do not exist in their own right. Unlike folders on disk, which have an entry in the file system on the disk itself, groups are just a particular text field in the entries stored in the database. The database contains these entries and the “group” structure for the Tree view is built as the entries are read in using whatever is in the “group” field in that entry. The group structure is built only from the entries stored in the database.
In version 3.29, we decided to remember “empty groups” in the database header (See FormatV3.txt or FormatV4.txt - header field with a value of 0x11). There is one of these for every group that can't be built from an entry in the database i.e. an empty group.. During normal processing, when a new empty group is created it is added to this list kept in memory, when one is deleted it is removed and when an entry is added to an empty group making it non-empty, it is also removed from this list. When the database is saved, the current empty group list is written to the header so that they can be shown the next time the database is opened. We do not keep any history of empty groups.
I hope this helps.
Note: Undo only works in the current session. When a database is closed, the Undo chain is deleted.
This seems to be a recurring issue because they expect groups to behave
like directories (aka folders) of file systems. Perhaps it's worth a small
change to complete the illusion of being a directory. Is there any downside
to having an empty group added to the list in memory when the last entry is
removed (deleted or moved)? This would mean folks would need to manually
delete empty groups but that seems to be most folks expectation already. If
someone really doesn't want this change in behavior then perhaps a
configuration setting could toggle automatic removal of empty directories.
In any case, thank you to everyone for contributing (e.g. code, support,
testing, etc.) to the application. Keep calm and carry on!
Lot's of things are possible, although I am not sure as to how "small" the change will be to implement. Luckily the header does already have a field to store the information. I will have to research the development effort required.
I suggest that this Bug Report is closed (it isn't a bug) and a new Feature Request is raised to track any development effort if we decide to implement.
After a quick review, this implementation is not trivial or quick. I suggest that you raise a Feature Request so that it can be tracked.
This bug report can be closed. Discussion may continue with the following feature request:
https://sourceforge.net/p/passwordsafe/feature-requests/806/