[Storage] Improve how GetFile handles paths

[a-maurice]

Description

Provide details of the change, and generalize the change in the PR title above.

On iOS, allow absolute paths to be passed in to GetFile, instead of just file URLs.

---

Testing

Describe how you've tested these changes. Link any manually triggered Integration tests or CPP binary SDK Packaging Github Action workflows, if applicable.

---

Type of Change

Place an x the applicable box:

• Bug fix. Add the issue # below if applicable.
• New feature. A non-breaking change which adds functionality.
• Other, such as a build process or documentation change.

---

#1724

Notes

• Bug fixes and feature changes require an update to the Release Notes section of release_build_files/readme.md.
• Read the contribution guidelines CONTRIBUTING.md.
• Changes to the public API require an internal API review. If you'd like to help us make Firebase APIs better, please propose your change in a feature request so that we can discuss it together.

[gemini-code-assist]

Summary of Changes

Hello @a-maurice, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a usability and robustness issue in the Firebase Storage GetFile method on iOS. It enhances the method's path handling capabilities, allowing it to correctly interpret and process both file:// prefixed URLs and absolute file system paths. This change simplifies API usage for developers and includes explicit error handling for invalid path conversions.

Highlights

• Improved iOS GetFile Path Handling: The GetFile method on iOS now intelligently determines if an input string is a file:// URL or an absolute file path, converting it to the appropriate NSURL object. This allows developers to pass absolute paths directly without needing to prepend file://.
• Enhanced Error Handling: Added a check in GetFile to ensure the provided path can be successfully converted to a valid NSURL. If the conversion fails, the operation will now complete with an kErrorUnknown status and a descriptive error message.
• Integration Test Adaptation: A temporary modification was made to an integration test (TestPutFileAndGetFile) to validate the new GetFile behavior, specifically testing its ability to handle paths without the file:// prefix.
• Release Notes Entry: An entry has been added to the release_build_files/readme.md under the 'Upcoming' section to document this improvement in the upcoming release notes.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

✅  Integration test succeeded!

Requested by @a-maurice on commit fd6fcf3
Last updated: Wed Aug 6 15:36 PDT 2025
View integration test log & download artifacts

[gemini-code-assist]

Code Review

This pull request updates the iOS implementation of GetFile to handle absolute file paths in addition to file URIs. The core logic change is sound, but I've identified a couple of issues: an edge case with empty paths that should be handled, and some temporary test code that needs to be cleaned up before merging.

[paulb777]

Can this be breaking since before it always used URLWithString and now it only uses URLWithString if there is a file:// prefix?

[a-maurice]

I think previously it would fail later if you tried to use a different url type, since it is calling into Storage ObjC's writeToFile, which is documented to take in a fileUrl (though looking over the code, I don't immediately spot anything that enforces that). The other possibility I was thinking of doing was trying URLWithString first, and if that returns nil fall back to fileURLWithPath. Do you think that would make more sense (and it would resolve the problem you are describing)?

[paulb777]

Yep, that would seem like a safer change to do URLWithString first and fall back. However, I'm also ok as is, if you've tested the different combinations.

[a-maurice]

I'll change it to that then, just in case there is some odd case I'm not aware of.

[a-maurice]

So, I tried that, and it has it's own weird problems of URLWithString succeeding and generating not nil, but incorrect file urls from the full paths. So I think I will go with checking for "file://", since it does seem to be necessary for the writeToFile logic anyway.