How to direct BC4 to completely ignore the .ori extension on Windows

[davea1]

Now that Windows 10 has defined a default file type for the ORI file extension, this has "broken" file BC4 comparisons between files of the pattern <file.ext> and <file.ext.ori>.

How can I direct BC4 to ignore the Windows default file type for files with an ORI extension in *all cases*, including the use case of comparing across 2 folders where an instance of <file.ext.ori> exists in each?

This issue has become a *tremendous* irritation. The ORI file extension is commonly used to designate an "original" copy of a file and I have been using it as such for decades for all file types. "Picture Compare" is *not* what I want BC4 to use in 95% (or more) use cases, though it would be if the "base" file extension type was actually a common image file type (such as BMP or PNG).


I realize that it was actually a Windows 10 change that actually triggered the issue, but there should be a method within BC4 to mitigate this issue.


Being an experienced software developer, I had attempted to hack the Windows Registry to remove the association, but it is wired a bit deeper than I anticipated. I also later realized this would not be a desired approach since this is now apparently a real/legitimate file type (though badly chosen IMO) and therefore a user might often want the default Windows functionality to continue for this file type outsize of BC4.


Basically, I need a method to direct BC4 to mimic the behavior that existed when running on earlier versions of Windows where this extension type was not defined by default without modifying the Windows OS configuration.


*Note* - simply mapping ORI files to another file extension type within BC4 is not an option since this extension is used to mark an "original" copy of a file for *all* file types (examples: TXT/C/PY/PS1/BAT/GO/PNG/BMP/DOCX/XLSX/PDF) and not just one base file type.

Thanks.

[Aaron]

Hello,

BC4's File Format list, if it falls through, will use the host OS to determine the file type, and the priority list of defined file formats is what we currently support to override that.

To mimic earlier behavior, if you create a New + Text format, and placing it at the bottom of the list, associated with *.ori. This would open them in the Text Compare, which was the previous default, correct?

Also, you could define a manual Alignment Override in the Session Settings, Misc tab, New Alignment Override:
*
=
*.ori

This would align the original name on the left to the Ori version on the right. Session Settings are specific for the current view, but could also be applied as a new global default going forward.

[davea1]

Hi Aaron,

Thanks for the quick response.

The desired behavior would be an option setting within BC4 to effectively ignore the ORI extension entirely and use the host OS to determine the file type of the non-ORI decorated file name in order to determine which type of comparison to utilize.

Since, if I recall correctly, ORI had no default file type association defined for older Windows versions, I believe this was the 'earlier behavior' when running BC4 on those systems. However, I could be remembering incorrectly.


Examples (desired behavior):

file.txt.ori <--> file.txt Use Text Compare based on TXT file type
file.bmp.ori <--> file.bmp Use Picture Compare base on BMP file type
file.reg.ori <--> file.reg Use Registry Compare based on REG file type


Would one (or more - see additional *Note* below) manual Alignment Override settings, as you have suggested, accomplish this behavior?

*Note* - This would need to "work" as expected regardless as to whether the *.ori file appeared on the left or the right of the comparison.

-Dave

[Aaron]

You're right. The new change to Windows does override this older behavior, and unfortunately this also overrides the Alignment Override solution I thought was going to work.

We don't have a good workaround to handle all cases. The best workaround is to define a Text Format (if that covers 95%) for *.ori files. Additionally, you *can* define sub-formats (higher in the list), so the total list is something like:
*.bmp.ori (picture format)
*.reg.ori (registry format)
*.ori (text format)
and it would fall through this list, looking for matches, to help increase to ~98%.

Adding an enhancement to define specific extensions as an ignorable backup is a wishlist item I've made, but it's not likely a feature we'll be able to implement short-term.

[davea1]

Understood. Thanks for the update.

Your workaround should at least allow me to minimize this annoyance until such a feature can be implemented long-term.

Maybe this discussion will help bump this feature up a bit on the wishlist.

-Dave

[Aaron]

I did add all of those notes, scenario, and the impact of picture extensions on the behavior.

[davea1]

After some experimentation, I discovered that creating "simple" sub-format entries was not sufficient since, by default, they would not contain any file Conversion or Grammar information.

Here is the process I ultimately followed in order to obtain reasonably acceptable behavior:

1) Created:

*.ori (text format) and named it: "Original Files"

2) Created "fully-functional" sub-formats (higher in the list) by: cloning the following existing File Formats (via Save As), renaming the clones as "* Original" and adding .ori to each entry stored within their respective file Masks:

Picture Files
Registry Dumps
PDF Documents
MS Excel Workbooks
MS Word Documents
RTF Files
C,C++,C#,ObjC Source
HTML Source
Java Source
JavaScript Source
Python Scripts
XML Source

I think what might possibly be needed here in order to truly support handling this type of issue is some sort of file type mapping option whereby the user could define something equivalent to:

*.ori = *

-Dave

[davea1]

Hi @Aaron,

Be sure to include all my latest details regarding the need to ensure proper file Conversion and Grammar behavior when comparing *.ori files.

Thanks,
-Dave

[Aaron]

Oh, sorry, yes, I had read and updated our notes with your updates; I just didn't have anything to add to the conversation besides that.

Hopefully if other users encounter this issue specific to .ori files, they'll find this thread as well for a good workaround.