This is something to be aware of. Yes, making sure workstations upgrade to 19.5.3 is part of the fix, but perhaps connections with 19.5.2 should be terminated upon login.
4 Likes
that's not a fix it is a disaster telling to use a hex editor on a file!
1 Like
I think someone who ends up being unable to open the file will implement just about anything to gain back access to a file. There is a likeliness that sending the file to Claris for repair results in something similar.
All in all, this bug is a bad one, and avoiding it in the first place sounds like the best "remedy" to me (I know typically a remedy is something you take after the fact, but I am simply saying that no remedy beats prevention). This is why I suggest testing for that version in a file startup script and close the file down when the version being used is the one that is prone to this bug.
2 Likes
Also related is this other community post: Claris Community (English)
1 Like
I know what you mean - but the fix is available and it works.
It works if your file does not have Encryption at Rest enabled. This is really the kind of glitch we should make some effort to avoid. Cost of prevention is negligible, the cost if the file cannot be open is on a totally different scale.
2 Likes
Yes, it is best practice to validate the client configuration that is trying to open a FileMaker system and either:
- quit the system (and create a help request) or
- create a help request to upgrade the installation on a non-emergency basis.
The functions that might be used include...
- Get ( Device )
- Get ( SystemPlatform )
- Get ( SystemVersion )
- Get ( ApplicationVersion )
- Get ( ApplicationArchitecture )
...with Get ( SystemPlatform ) and Get ( ApplicationVersion ) likely to be the most useful.
Get ( EncryptionState ) could also added to note the level of risk.
A script that...
- is called on system/file opening
- branches using the functions above
- filters against white lists of tested configurations
...would add an additional measure of protection and also buy time to address in other ways.
There are lots of types of customers and lots of FM system architectures. And there are other things that can be done to protect against this issue.
Happy to hear other thoughts on how to address this challenge.
Thank you for sharing this. I just implemented in all my solutions a test on startup so anyone using 19.5.2 loses access to the "File" menu and gets an alert to update. That should be safe, right? I just want to make sure I'm not missing any other minor details of this
I would favor changing the file options to make the minimum version 19.5.3. If I cannot do that because version of 19.5.1 or prior need to connect, I would test for the version 19.5.2 specifically and close the file down (after showing a custom dialog), without attempting to leave the user in, but having to manage access to menu or script commands that prompt open the same dialog. It may be draconian, but I prefer to be on the safe side. I could explain myself easily with anyone who would feel like this measure generates too much discomfort.
If anyone wants to keep using 19.5.2 after being advised of the possible repercussions, I would ask the customer to sign a release form to the effect they were informed about the problem this could lead to, but chose to disregard their vendor's recommendation in this matter.
19.5.2 is simply not a configuration I want to support. I do not feel like the risk is worth it.
- validate the client configuration on FM System Open
- proof of concept...validate versions that might be [A] higher and have issues or [B] older and not have features that are used, etc.
- *** more that one way to write the code to achieve the goals. See below (simple version using illogical appVersion sample data and template code).
It is worth noting from the release notes of 19.5.4 that the newer software will now open the problematic files. There is no mention about Encryption At Rest, and the release notes also do not mention what new value gets inserted as the minimum version required to open the file.
I also do not know if the fix is silent or the user gets notified of a change to that section, but in order for a fix to be implemented, that minimum version needs to be re-written and there is no way for the software to guess the value you need to see there, so you should pay attention to that after the file gets "fixed".
3 Likes
FMP 19.5.4 resets the minimum version to 12.0 if it was "damaged" by this bug. The fix is applied silently and no logging is done for it (like with import.log, recovery.log, conversion.log...). The same should happen on FMS but I haven't tested it there yet.
7 Likes
Thank you for the additional detail @soliantkarl
2 Likes
@soliantkarl does this work for files with EAR applied? I'm assuming so… but I don't like to assume anything in the world of agile development. 
2 Likes
@flybynight My fix doesn't work with EAR files but FMP 19.5.4 (released yesterday on Sep 20, 2022) does fix this bug.
1 Like
To clarify, here's the timeline of this bug:
- July 18, 2022: Earliest report of this bug that I can see.
- Aug 27, 2022: I heard about the bug for the first time and published the fix on the same day.
- Aug 31, 2022: FileMaker Pro 19.5.3 was released. This release prevents this bug from happening but doesn't resolve it for files already affected by this bug.
- Sep 13, 2022: The Soliant blog post about this bug was published. Fixing the "Convert this Database" Bug
- Sep 20, 2022: FileMaker Pro 19.5.4 was released, and it can fix files affected by this bug.
@FileKraft, I agree that we should avoid tampering with client applications using hex editors.
In the post where I provided instructions about the fix, I wrote that the "fixed" file should not be used even though it's functional, but some didn't have unaffected backups of their files. It was a useful temporary fix until Claris released an official one. The hex editor was unavoidable to multiple FM devs, especially those whose clients urgently needed access to their systems (such as medical clinics).
2 Likes
@soliantkarl thanks for confirming… yes, I was asking about 19.5.4, since they didn't explicitly say it worked on EAR files.
It might be nice if you added an update/addendum to your blog post about 19.5.4, mentioning encrypted files, and also the v12.0 that is silently applies as the minimum.
when there is a bug of this severity (complete data loss) communicate everything and don't outsource to third parties if responsible...
yes great that @soliantkarl offered quick rescue!
4 Likes
I was going to wait seven days before posting an update about 19.5.4 in case a worse problem arose, but I don't think it's necessary in this case. I just submitted the update, and it is now in the process of being published.
Thank you for your advice.
5 Likes