Fix getPathFromUri returning truncated files when copy ends early

[Suraj2105-1]

Fixes issue #193077 where getPathFromUri silently returns a truncated file when a cloud-backed provider's stream ends early.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request updates FileUtils.java to verify that the copied file size matches the expected image size, deleting the partial file and returning null if it is smaller. Review feedback suggests closing the output stream before deleting the file to prevent file handle issues on certain operating systems, and using cursor.getColumnIndex instead of a hardcoded index to retrieve the image size more robustly.

[gemini-code-assist]

Attempting to delete outputFile while outputStream is still open can fail on some operating systems (like Windows) or filesystems because the file handle is still active. It is safer to close the stream before deleting the file.

        if (expectedSize != null && expectedSize > 0 && totalBytesCopied < expectedSize) {
          Log.w("FileUtils", "File copied is smaller than expected size (" + totalBytesCopied + " < " + expectedSize + "); deleting partial file.");
          try {
            outputStream.close();
          } catch (IOException ignored) {
          }
          outputFile.delete();
          return null;
        }