Copying files fails after 4294967295 bytes were written on external ntfs hdd. |
|||||||||||
Issue descriptionChrome Version: 62.0.3202.82 Chrome OS Version: 9901.66.0 (Official Build) stable-channel link Chrome OS Platform: chromebook pixel 1 Network info: should not matter, it's an openwrt running on something high-end tp-link Steps To Reproduce: (1) Download a file (from, say, yandex disk) that is larger than 5GiB (2) insert an external usb hdd with ntfs on it (3) copy the file to the hard drive Expected Result: The operations succeeds Actual Result: The operation fails leaving the file with only 4294967295 on it. How frequently does this problem reproduce? Always, tried 2 times, got bored. What is the impact to the user, and is there a workaround? A possible workaround is to copy the file to a network share or a USB flash drive, but I have not tried those.
,
Dec 1 2017
4294967295 = 0xFFFFFFFF = 2^32 - 1 = maximum 32-bit unsigned integer. Apparently the file manager doesn't properly utilize 64-bit.
,
Feb 19 2018
<files-triage>
,
Feb 20 2018
,
Feb 20 2018
,
Feb 28 2018
,
Mar 28 2018
,
Apr 3 2018
I can reproduce this issue on ToT. 1) Format a USB to NTFS (using gparted, for example) 2) Navigate to the USB and run the following command to create a 5GB file: $ dd if=/dev/zero iflag=count_bytes count=5G bs=1M of=large; sync 3) Plug the USB into a chromebook; copy the file to the chromebook and back again
,
Apr 5 2018
,
Jun 5 2018
,
Jun 6 2018
Unable to repro on chell. But link has a different kernel version, so I'll try and hunt down one (or another device running 3.8, chell runs 3.18).
,
Jun 6 2018
Unable to repro on link: Google Chrome 68.0.3440.4 (Official Build) dev (64-bit) Platform 10718.4.0 (Official Build) dev-channel link
,
Jun 15 2018
Unable to repro on an M63 build. Tried M62, but it kept crashing on my chell. Need more information, or someone that can reliably repro this.
,
Aug 7
I can't repro this anywhere (even tried a 32-bit machine). Without that, there's not much I can do. I've come across feedback reports of this. But in those cases, the user was using a FAT32 formatted drive. I've filed a separate bug to handle this case better.
,
Sep 9
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by weifangsun@chromium.org
, Dec 1 2017