Photo by Tim Mossholder / Unsplash

Hasselblad FFF vs 3FR: Why Renaming Doesn't Work (And Why That's Good)

Konrad Michels
Konrad Michels

Table of Contents

This started with a question on a Hasselblad forum: someone tried renaming a .FFF file to .3FR hoping Phocus Mobile 2 would recognize it. It didn't work. The ensuing discussion turned into an impromptu explainer about how file extensions, file associations, and file validation actually work at a technical level - and why "just rename it" is almost never the answer.

If you've ever wondered why you can't trick software by changing a file extension, and even if you didn't, this is for you.


If you'd like to support this documentation project: ☕ Buy me a coffee

What Actually Happens When You Double-Click a File

There are three distinct things happening when you open a file, and people often conflate them:

File Association (OS level)

When you double-click a file, your operating system checks the extension against a registry of associations and launches the corresponding application. This is purely extension-driven - macOS doesn't examine the file's contents to make this decision. It just sees ".3FR" and thinks "Phocus handles those."

File Interpretation (Application level)

The OS doesn't actually execute anything inside the file. It's just a matchmaker. It finds the associated application, launches it, and hands over the file path. The application does all the actual work: parsing the contents, interpreting the structure, and rendering something useful on screen.

File Validation (Application level)

This is where things get interesting. Most well-designed applications perform input validation before proceeding. They check file headers, magic bytes, and internal structure - they don't just trust the extension. Rename a JPEG to .psd and Photoshop will refuse to open it, because the internal structure doesn't match what a PSD should contain.


Why This Is Application Security 101

red and black love lock
Photo by FlyD / Unsplash

Here's where my former life in tech shows through. I spent years in Facebook's AppSec organisation, including time with the Bug Bounty team, and one of the many foundational principles we operated on was this:

Never trust user-controllable metadata.

The filename is just a label that travels with the file - it isn't part of the file itself. Anyone can change it at any time. Software that bases critical decisions on filenames alone has effectively handed control of its behaviour to the user. Or worse, to someone with malicious intent.

This is the same principle behind why web servers don't just trust file extensions to determine MIME types for uploads. It's why email security scanners examine file contents rather than trusting that the attachment labelled "invoice.pdf" is actually a PDF. The extension is a hint, not a guarantee.

When Phocus Mobile 2 refuses to open your renamed FFF file, it's not being stubborn. It's doing exactly what secure, mature software should do: validating that the file actually is what it claims to be.


Why FFF and 3FR Aren't Just Different Labels

This brings us to the Hasselblad-specific part. FFF and 3FR aren't just different extensions for identical data - they have different internal structures.¹

Based on observed behaviour in Phocus 4.0.1:²

  • 3FR files are the original RAW files written by the camera to the CFexpress card or internal SSD. They include the full sensor data, embedded JPEG previews, and the complete metadata structure.
  • FFF files appear to be containers that Phocus generates when the camera is connected in tethered mode. They're created from image data received over the communication protocol, and they don't include the embedded JPEG preview or the exact metadata structure of a native 3FR.

When Phocus Mobile 2 examines your file, it reads the header and validates that the internal structure matches the 3FR specification. The extension is irrelevant to that check. If the structure says "I'm an FFF," then that's what it is - regardless of what you've named it.


Why This Is Good Design, Not a Limitation

It's tempting to see this behaviour as an annoyance. But consider the alternative: software that trusts whatever you tell it.

That's how you get security vulnerabilities. That's how you get corrupted files when someone accidentally renames things. That's how you get unpredictable behaviour that's nearly impossible to debug.

Phocus validating file structure isn't a limitation - it's the software doing its job properly. The fact that renaming doesn't work is evidence of good engineering, not bad.


The Practical Takeaway

If you have FFF files and need 3FR files (or vice versa), renaming won't help. These are fundamentally different file structures, and the software knows the difference.

For more on how 3FR and FFF files behave differently in everyday Phocus workflows - including why you might end up with FFFs when you expected 3FRs - see Understanding Hasselblad Phocus on macOS.


I'd love your feedback on this post, or any of my other posts. I'd also love to hear any ideas for topics I haven't yet covered that you'd like me to look into.

Or even other content about the topics I've written about which I haven't referenced. I am always open to learning more.

Send me feedback!

References

  1. Based on observed differences in how Phocus 4.0.1 handles files imported via Mass Storage mode (3FR) versus tethered mode (FFF). Hasselblad has not publicly documented the exact structural differences between these formats.
  2. See "Importing When the Camera Is Already Connected and Why Files May Appear as FFFs" in Understanding Hasselblad Phocus on macOS - The Hidden Rules Behind 3FR, FFF, HNCS, and HNNR.

Comments