Local Backup File Names (Q Mac)

William Day

The file names that Quicken has assigned to the LOCAL Automatic BACKUPS are very confusing.  When reviewing the file names in the local backup folder one would expect that the file name at the end of the list might designate the most recent backup.  Unfortunately this is not the case.  Below is a list of my most recent five (5) local backups: 

1-  "BACKUP (Automatic) - QuickenData 2024-11-21 (2).quickenbackup" 

2 - "BACKUP (Automatic) - QuickenData 2024-11-21 (3).quickenbackup"

3 - "BACKUP (Automatic) - QuickenData 2024-11-22 (2).quickenbackup"

4 - "BACKUP (Automatic) - QuickenData 2024-11-22 (3).quickenbackup"

5 - "BACKUP (Automatic) - QuickenData 2024-11-22.quickenbackup"

From the list one would think that "BACKUP (Automatic) - QuickenData 2024-11-22.quickenbackup" (number 5) was the most recent / newest backup.  But that is not the case; the most recent local backup is number 4 "BACKUP (Automatic) - QuickenData 2024-11-22 (3).quickenbackup”. In my opinion, Quicken needs to address this confusing issue.

Jon

Maybe I'm just used to the way it works but I think even if I was a new user I would expect it to work the way it does; Quicken isn't the only program I have that will start appending numbers when there are duplicate file names so I'm accustomed to looking for the highest number. But then I usually look at file date & time before I look at names when trying to find the "most recent".

BK

From the list one would think that "BACKUP (Automatic) - QuickenData 2024-11-22.quickenbackup" (number 5) was the most recent / newest backup.

With one glance it was clear to me that number 5 is the oldest of 3,4,5 in your example. Perhaps confusing to some and not to others, to my knowledge in most OS, file iterations with the same name & date follow a similar nomenclature by default: oldest to newest being DataFile, DataFile (1), DataFile (2), etc.

Also adding the time-stamp to the backup file should eliminate any confusion.

William Day

Perhaps if the #5 Backup had a suffix (1) there would be no confusion on any one's part & one not need to be a 'techee' to recognize that #4 was the most recent backup. And the current no suffix number would put the backups in the correct order Oldest at the TOP in the catalogue listing and Newest at the BOTTOM of the catalogue listing. Quicken appears to have addressed this issue in their newly offered ONLINE BACKUP release for Mac Classic Deluxe insuring that the most recent online backup appears at the TOP of the Online Backup List.

jacobs

@William Day The order of local backups is shown in a standard macOS window. By default, that's in alphabetical order by name. But if you want to see the backups from newest to oldest, just click on the Date Modified heading twice (so it is showing "Date Modified v"), and the files will be sorted in descending date/timne order. This isn't a Quicken issue; it's how all Finder windows and Open/Save dialog boxes work in macOS.

William Day

In my opinion Quicken should be releasing a product that doesn't require a detailed knowledge of Mac OS.

Quicken needs to be 'user friendly' when it comes to backups.

Quicken should be naming their Local Backups with file names that automatically place the most recent local backup at either the TOP or BOTTOM of the Catalogue list. Quicken is doing this with their ONLINE BACKUPS why can't this be done with the LOCAL BACKUPS?

In addition the most recent backup should be consistent between the LOCAL & ONLINE location (either both at the TOP of a catalogue list or both at the BOTTOM of a catalogue list).

jacobs

@William Day I guess we'll have to agree to disagree. 😁

I don't think looking at a folder and changing its sort order constitutes "a detailed knowledge of macOS". Having nothing to do with Quicken, it's second nature to me when opening any folder on a Mac that if I don't immediately spot what I'm looking for, I can change the sort order of the folder to alphabetical or date modified, whichever will help me most quickly locate what I'm looking for.

Quicken should be naming their Local Backups with file names that automatically place the most recent local backup at either the TOP or BOTTOM of the Catalogue list.

Quicken doesn't control the display of a Finder/Open/Save window, as it is populated by macOS. And since the user controls the order, no matter how Quicken names the files, the user can change the order. For instance, let's say Quicken named its backup files:
2024-11-25 Backup 1
2024-11-25 Backup 2
2024-11-25 Backup 3

…then by clicking on the Name heading, I can toggle #1 to the bottom or the top each time I click on the heading. That's just how macOS works.

It seems like what you're suggesting would require Quicken to design and program its own user interface for displaying backup files. Aside from taking time away from other features on the wishlist, I can think of several reasons this might not work well or be totally impractical. One is that each time you install a versions upgrade, Quicken automatically makes a pre-update backup, in a separate folder within your backup folder. How would/should Quicken display these backups relative to the regular automatic backups. Also, a user can manually generate a backup anytime they want. (I do this every month or two, so I have a trail of older backups which won't be automatically deleted by Quicken over time.) How would Quicken integrate these into a custom backup window?

In addition the most recent backup should be consistent between the LOCAL & ONLINE location (either both at the TOP of a catalogue list or both at the BOTTOM of a catalogue list).

Sorry, but I don't see it that way, simply because the local backups are displayed like every other folder on a Mac — where the order is controlled by the user. If you want most recent at the bottom, click the Date Modified heading; if you want most recent at the top, click Date Modified a second time.

I appreciate that you didn't understand how Quicken names its backups, and that the display of the order of the backups was something you could control by clicking on the Date Modified heading. But here's what I think is a key question: now that you know it, you'll never have confusion about identifying the most recent backup again, right?

But if you think this is an issue Quicken should address by building its own user interface for local backups, you should create an Idea post for it, where other users can comment and vote on it, and, if it acquires enough votes from like-minder Quicken Mac users, it will get passed on to the developers for consideration. Navigate in this forum to Product Ideas > Ideas for Mac Classic > Backups and File Conversion, and then click the big blue New Idea button on the upper right.

William Day

Thank you Jacob for devoting so much time addressing the issue of local backups: but I don't think that this is a 'New Idea' that requires Community voting. In my opinion this is a BUG in the Quicken file naming convention for local backups. For example, were Quicken to change its local backup filename convention to reflect

(1) the date (YYYYMMDD) and military time , HHMMSS (where H =00-23, M =00-59, SS =00-59) as part of the file name OR -

(2) the date (YYYYMMDD) and time as AM or PM followed by HHMMSS where HH=00-11, MM=00-59, SS=00-59

the sequencing issue would be resolved; the most recent backup would appear last in the catalogue list and the need for a user to alter the default MAC OS catalogue presentation would not be needed.

Just a thought ……… I don't think that Quicken should address this issue by building its own user interface (as suggested above) for local backups but just make a small change in the local backup file naming convention. This is my last post on this MAC > Quicken Classic Deluxe > Local Backup Issue. Thank you for your attention to this issue.

jacobs

Thank you Jacob for devoting so much time addressing the issue of local backups: but I don't think that this is a 'New Idea' that requires Community voting. In my opinion this is a BUG in the Quicken file naming convention for local backups.

@William Day For whatever it's worth, I've learned from working with these (and other) developers that something like this not considered a bug because it is working as it was intended/designed. Only things which aren't operating as designed are considered bugs by the developers.

That doesn't necessarily mean the design is good, or that there isn't a better design which would make using the program better or easier. But even when a change may seem to be a plainly obvious improvement, it's still an enhancement request competing for development time against hundreds of other possible improvements. That's why there are Idea threads with voting on this site: to show the developers if an enhancement request has support from more than a single or a few users.