Why are framemaker backup files not saved with a different file extension?

[Ian16B7]

I use FM2020, DITA 1.3. My file types are therefore .dita. Whenever FM creates a backup file, it names the backup file as <filename>.backup.dita. This unfortunate choice means that all of my backup files get interspersed/mixed with the original files, because they all have the same .dita extension. As a result, it is awkward to organize/sort files in Windows explorer , open a file that I want within FM, etc.

I think that every other program that I have ever used chose to give backup files a different extension (e.g. .bak), so that it is easy to manage them.

Is there a way to change this behaviour in FM2020? Is there a reason why Adobe did not choose a different file extension?  I found a number of other Framemaker posts on this forum requesting that the backup files go into a different folder, as a different solution to this same problem, so I think that others find this behaviour awkward as well (but I do not think that solution has been implement either).  

[LinSims]

There is no way within FM to change this.

You can make a feature request using the Adobe Tracker for FrameMaker: https://tracker.adobe.com/#/home

I usually "tidy up" my directories at the end of the day by searching for *.backup.* and then deleting the results. It's a bit of a pain, but it works.

[Ian16B7]

Thanks for the suggestion. I have created a feature request:

For those in favour, please up-vote at https://tracker.adobe.com/#/view/FRMAKER-9672 

[Bob_Niland]

That link has some stray characters at the end. Try this one:
https://tracker.adobe.com/#/view/FRMAKER-9672

If FM gets such a feature, I'll use it.
This connundrum has likely been around since FM first settled on the .fm file name extension (FM4?). And until Win95, extensions were limited to 3 characters.

.backup. may be coded into more places than just auto-save. Does FM look for a .backup.fm or .backup.book in the wake of crash recovery?

What are the implications for existing scripts & 3rd party apps? If any, then legacy behavior would have to remain an option.

Then we get to possible convention options.

.bak has been used on DOS/Win systems forever, and is apt to have a random association on any random Windows systems. You might not care.

Dedicated extensions (e.g. .fmbk, .ditabk, etc.) might require some research to assure that they are not already in use by other apps.

Actually, it might suffice to option an alternative to that inner ".". If .backup.fm were simply .backup_fm, Windows would see the whole string as the filename extension, rather than just the trailing .fm

[Winfried Reng]

Ian, both approaches have their pros and cons. I like it that backup files have the same extension. It's clear that they are regular FrameMaker files. In the file manager, which I use, Total Commander I can very easily filter the display of files for files with certain text (e.g. backup) and move, delete or whatever.

You could write an ExtendScript script (or ask someone to do this for you) which moves backup files into a subfolder and/or changes the file name extension.

And write a feature request as Lin suggested. When you post the link here, others can vote for this request.

Lin, why do you have backups activated, when you delete them anyway?

[LinSims]

Mostly because I never bothered to turn it off, but also because it's a backup for during the daily work. 

[LinSims]

It occurs to me that one of the reasons might be to ensure that the backup files open in FrameMaker by default. They are full FrameMaker files, after all, since all they are is the previous version of a file after you make a save.

[Bob_Niland]

LinSims: … one of the reasons might be to ensure that the backup files open in FrameMaker by default.

That's not a limiter.
FM already has to setup Registry (I presume) association for multiple extensions, like .fm, .book, .dita, perhaps .mif & others. Adding one or two more (e.g. .backup_book, .backup_fm) isn't that big a deal. The major challenge is stepping out of the legacy behavior, and taking inventory of the possible unintended consequences before doing so.

And frankly, although I would use such an enhancement, it's way down the list of things I'd like to see addressed, such as spot-Xref, Unicode SMP, hovertext-into-PDF, PDF/A-4, CAD-like callout leaders, flowing more HTML & CSS capabilities back into FM {like <HR, rounded table corners} etc.

[LinSims]

I'm hoping they fix the decimal tab alignment in tables, myself. 

[Bob_Niland]

LinSims: I'm hoping they fix the decimal tab alignment in tables, myself.

Yep. The lack of SMP support is already preventing me from releasing a document in PDF/A-2u (or -3u, but I don't need -3 features).

Even so, I have to use Acrobat Pro to post-convert to PDF/A-2b (~2011), because the PDF setup in FM (unstructured, anyway) can only directly generate PDF/A-1b so far. PDF/A-4 (2020) isn't a factor yet.
But then, document & font standards aren't a feature; they're a treadmill.

[Matt-Tech Comm Tools]

Bob, this is off-topic, but are you saying you can't produce PDF/A-2b in Fm 2020?

Have you seen the .joboptions in 
C:\Users\(username)\AppData\Roaming\Adobe\FrameMaker\16\Additional_PDF_Settings ?

For anyone not familiar with adding .joboptions in Fm, here's a video discussing PDF/A and PDF/X improvements in Fm 2020:

https://www.youtube.com/watch?v=B5-Nl7sMvoE&list=PLJL3v-Ayk9rR1aAJKIhj4fPN0B79t_FW9&index=20

[Bob_Niland]

Reply moved to: New job options in FrameMaker 2020

[Winfried Reng]

Hi Matt,

Thank you very much for reminding me of these additional new job options.

Do you know why there json and joboptions file name extensions?

And do have a description of these new job options? In particular:

Cleaner_Defaults.joboptions
LiquidModePDF.joboptions
Mobile.joboptions
PDF20.joboptions

What is the difference?

Best regards

Winfried