Eliaaazzz opened a new pull request, #668:
URL: https://github.com/apache/cordova-plugin-file/pull/668
### Platforms affected
Android
### Motivation and Context
Fixes #667.
Writes above a 2 GB offset corrupt the file on Android. The `write` and
`truncate` actions parse the offset with `JSONArray.getInt()`, and Android's
`org.json` narrows large values instead of throwing:
```java
JSONArray args = new JSONArray("[\"file\",\"data\",3000000000,true]");
args.getInt(2); // -1294967296
args.getLong(2); // 3000000000
```
The wrapped offset is negative, so `LocalFilesystem.writeToFileAtURL()`
skips its truncate-and-append path (`offset > 0` is false) and overwrites the
file from position 0 — exactly the corruption reported in the issue.
### Description
Carries the offset as a `long` from the bridge down to the filesystem
implementations:
- `FileUtils.java`: `args.getInt(...)` → `args.getLong(...)` in the `write`
action, the `truncate` action, and the post-permission `ACTION_WRITE` retry
path; `write()` now takes `long offset`.
- `Filesystem.java`: abstract `writeToFileAtURL(..., long offset, ...)`.
- `LocalFilesystem.java`, `AssetFilesystem.java`, `ContentFilesystem.java`:
overrides updated to match.
The truncate chain (`truncateFile()` / `truncateFileAtURL()`) already used
`long` everywhere past the argument parsing, so only the parse site changes
there. Downstream consumers of the offset (`truncateFileAtURL()`,
`FileChannel.truncate()`) take `long` natively; no arithmetic on the offset
exists that would need range checks.
Per the discussion on the issue this is a breaking change to the
`Filesystem` abstract signature, so the commit is marked `fix(android)!:` with
a `BREAKING CHANGE:` footer, matching the 9.0.0-dev line this lands in. The JS
layer needs no change: it keeps the position as a plain double and never
coerces to 32 bits.
On the `Number.MAX_SAFE_INTEGER` point raised in the issue: values above
2^53−1 cannot be expressed reliably on the JS side to begin with, and the Java
side now faithfully carries anything that arrives. Happy to add an explicit
upper-bound assertion in `FileUtils` in this PR or a follow-up if you'd like
one.
### Testing
- Compiled all `src/android` sources with `javac` against the
cordova-android 14.0.1 `framework` classes, androidx, and the Android 13 (API
33) platform classes: compiles clean before and after the change (only the
pre-existing deprecation/unchecked notes).
- Verified the `getInt` wrap-around vs `getLong` behavior with Android's
`org.json` implementation (snippet above).
- `npm test` (eslint) passes.
- No automated test added: the mobile test suite runs on emulators where
creating a >2 GB file is impractical; the failure mode and fix are fully
determined by the integer narrowing shown above.
### Checklist
- [x] I've run the tests to see all new and existing tests pass
- [ ] I added automated test coverage as appropriate for this change
- [x] Commit is prefixed with `(platform)` if this change only applies to
one platform (e.g. `(android)`)
- [x] If this Pull Request resolves an issue, I linked to the issue in the
text above (and used the correct [keyword to close issues using
keywords](https://help.github.com/articles/closing-issues-using-keywords/))
- [x] I've updated the documentation if necessary
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
