# Formatting an SD card as Internal (Adoptable) Storage on Fire OS appears to change filename lookup behavior, causing native fopen() calls to fail when the requested filename differs only by letter case **URL:** \ **Category:** Q&A\ **Tags:** appstore-fire-tablet\ **Created:** [July 16, 2026, 8:27pm UTC](https://community.amazondeveloper.com/t/formatting-an-sd-card-as-internal-adoptable-storage-on-fire-os-appears-to-change-filename-lookup-behavior-causing-native-fopen-calls-to-fail-when-the-requested-filename-differs-only-by-letter-case/28767 "2026-07-16T20:27:15Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![tonykhar](https://avatars.discourse-cdn.com/v4/letter/t/6de8d8/32.png) [@tonykhar](https://community.amazondeveloper.com/u/tonykhar)\ **Post date:** [July 16, 2026, 8:27pm UTC](https://community.amazondeveloper.com/t/formatting-an-sd-card-as-internal-adoptable-storage-on-fire-os-appears-to-change-filename-lookup-behavior-causing-native-fopen-calls-to-fail-when-the-requested-filename-differs-only-by-letter-case/28767/1 "2026-07-16T20:27:15Z")
# ⚠ Before you continue * * * _Before submitting a bug report, please review our troubleshooting documentation at_ [Troubleshoot Issues | Vega Troubleshooting](https://developer.amazon.com/docs/vega/latest/troubleshoot-overview.html) _If you still want to file a bug report, please make sure to fill in all the details below and provide the necessary information._ **NOTE: PLEASE ONLY REPORT A SINGLE BUG USING THIS TEMPLATE.** _If you’re experiencing multiple issues, please file a separate report for each._ * * * # 👉 1. Summary ### Bug Description After formatting an SD card as **Internal (Adoptable) Storage** on a Fire tablet, native applications using standard C library file I/O (`fopen()`) experience case-sensitive filename resolution for files stored under `/sdcard`. Applications that previously functioned before storage migration may fail to locate existing files if the filename requested differs only by letter case. This behavior is reproducible using a minimal native test application and does not depend on any third-party SDK. **Impact** Applications that download resources using one filename capitalization but later open the same resource using different capitalization receive `ENOENT`, even though the file exists. **App Name** N/A (Reproduced using a standalone native test application.) **Bug Severity** ☑ Impacts operation of app * * * # 2. Steps to Reproduce 1. Insert an SD card into a Fire tablet. 2. Format the SD card as **Internal (Adoptable) Storage**. 3. Copy or create a file on adopted storage named: ```auto ``` ```auto CFGLIB_010000.BIN ``` 1. Execute: ```auto ``` ```auto FILE *fp = fopen("/sdcard/.../cfglib_010000.bin","rb"); ``` 1. Observe the return value. 2. Execute: ```auto ``` ```auto FILE *fp = fopen("/sdcard/.../CFGLIB_010000.BIN","rb"); ``` 1. Compare the result. * * * # 3. Observed Behavior The first call returns ```auto ``` ```auto NULL errno = ENOENT (2) "No such file or directory" ``` although the file exists. Changing only the filename capitalization causes the identical `fopen()` call to succeed. Example: ```auto ``` ```auto Stored filename: CFGLIB_010000.BIN Requested filename: cfglib_010000.bin ``` No other changes are required. The same application behavior worked correctly before the SD card was formatted as Internal (Adoptable) Storage. * * * # 4. Expected Behavior I would like clarification whether this is expected Fire OS behavior. If Adoptable Storage intentionally exposes case-sensitive pathname resolution through `/sdcard`, this behavior should be documented because native Android applications may rely on case-insensitive filename lookup after storage migration. If this is not intentional, it appears to be a compatibility issue introduced after formatting the SD card as Internal Storage. * * * # 4.a Possible Root Cause Investigation performed: - Filesystem verified as **F2FS** - `external_storage.casefold.enabled` is **unset** - Current AOSP `vold` formats adopted F2FS volumes without the `casefold` feature when this property is not enabled. - Native `fopen()` succeeds only when the pathname exactly matches the on-disk filename. Temporary workaround: Rename files so the stored filename exactly matches the filename passed to `fopen()`. * * * Native test output: ```auto ``` ```auto fopen("/sdcard/.../cfglib_010000.bin") NULL errno=2 No such file or directory -------------------------------- fopen("/sdcard/.../CFGLIB_010000.BIN") SUCCESS ``` * * * # Additional Context This issue was reproduced using a standalone native test program calling the standard libc `fopen()` API. The behavior is independent of any third-party application and appears to depend solely on filename case after the SD card has been formatted as Internal (Adoptable) Storage. **Question:** Is case-sensitive filename lookup through `/sdcard` expected behavior on Fire OS after Adoptable Storage is enabled, or is this an unintended compatibility change? ---
**Author:** ![amen](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@amen](https://community.amazondeveloper.com/u/amen)\ **Post date:** [July 16, 2026, 10:16pm UTC](https://community.amazondeveloper.com/t/formatting-an-sd-card-as-internal-adoptable-storage-on-fire-os-appears-to-change-filename-lookup-behavior-causing-native-fopen-calls-to-fail-when-the-requested-filename-differs-only-by-letter-case/28767/4 "2026-07-16T22:16:33Z")
Hi @tonykhar, Welcome to Amazon Developer Community!! Thank you for the thorough investigation and well-documented bug report. This is expected behavior. When an SD card is formatted as Internal (Adoptable) Storage on Fire OS, the filesystem is reformatted from FAT/exFAT to F2FS. Unlike FAT/exFAT, F2FS is case-sensitive by default - this means filename lookups via fopen() require an exact case match. Before adoption, the SD card uses FAT/exFAT, which is case-insensitive, so cfglib\_010000.bin would successfully resolve to CFGLIB\_010000.BIN. After adoption, the F2FS filesystem treats these as different filenames. This behavior is consistent with AOSP’s implementation of adoptable storage and is not specific to Fire OS. **Recommendation:** Applications should always use consistent filename casing when writing and reading files to ensure portability across different filesystem types (FAT, F2FS, ext4). Relying on case-insensitive filename resolution is not safe on Linux-based filesystems. Your workaround of matching the stored filename exactly in fopen() calls is the correct approach. Reference: Fire OS 6 - Adoptable Storage ( [Fire OS 6 for Fire Tablets | Fire Tablets](https://developer.amazon.com/docs/fire-tablets/fire-os-6.html) ) Best regards, Aishwarya M. ---
**Author:** ![tonykhar](https://avatars.discourse-cdn.com/v4/letter/t/6de8d8/32.png) [@tonykhar](https://community.amazondeveloper.com/u/tonykhar)\ **Post date:** [July 17, 2026, 1:11pm UTC](https://community.amazondeveloper.com/t/formatting-an-sd-card-as-internal-adoptable-storage-on-fire-os-appears-to-change-filename-lookup-behavior-causing-native-fopen-calls-to-fail-when-the-requested-filename-differs-only-by-letter-case/28767/5 "2026-07-17T13:11:49Z")
Hi @amen Thank you for the clarification. I understand now that this is expected behavior and that Fire OS is following AOSP’s implementation for Adoptable Storage. One observation I’d like to make is that, from both a developer’s and a user’s perspective, Fire OS provides a case-insensitive storage experience out of the box. Applications that use the tablet’s built-in storage operate without encountering this behavior. The change in filename semantics only becomes visible after an SD card is added and configured as Internal (Adoptable) Storage, where filename lookups transition from effectively case-insensitive to case-sensitive. While this is technically consistent with the underlying F2FS filesystem, it introduces a compatibility boundary that is largely invisible to end users. Existing native applications that have functioned correctly for years can suddenly stop locating resources after enabling expanded storage, without any changes to the application itself. I also wonder whether some of the reports from users describing applications or downloaded content no longer working after enabling Internal Storage are actually manifestations of this change in filename semantics rather than unrelated application issues. Since AOSP already includes optional F2FS casefold support through the `external_storage.casefold.enabled` property, would it be possible to expose this as an optional setting during the “Format as Internal Storage” process? For example: **Compatibility Mode (case-insensitive filename lookup)** This would provide a migration path for legacy applications while preserving the current default behavior for users who prefer standard Linux filesystem semantics. It would not alter the default Fire OS configuration or affect modern applications that already use consistent filename casing, but it could significantly improve compatibility for existing software that was developed under the assumption of case-insensitive storage behavior. Thanks You, Tony. ---
**Author:** ![system](https://dhm3gbtzu79o6.cloudfront.net/user_avatar/community.amazondeveloper.com/system/32/5065_2.png) [@system](https://community.amazondeveloper.com/u/system)\ **Post date:** [July 19, 2026, 1:12pm UTC](https://community.amazondeveloper.com/t/formatting-an-sd-card-as-internal-adoptable-storage-on-fire-os-appears-to-change-filename-lookup-behavior-causing-native-fopen-calls-to-fail-when-the-requested-filename-differs-only-by-letter-case/28767/6 "2026-07-19T13:12:20Z")
Closed on July 19, 2026, 1:12pm UTC This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.