Large video files reported as empty

[corsinpfister]

Describe the bug

In the output of gphoto2 --list-files, some (large) video files show up as files of size 0. When copied over via gphoto2 --get-all-files, they end up as empty files on my linux machine. On the camera's SD card, the videos are definitely there (I can watch them on the camera).

Name the camera

Canon EOS M50m2

libgphoto2 and gphoto2 version

gphoto2         2.5.28         gcc, popt(m), exif, no cdk, no aa, jpeg, readline
libgphoto2      2.5.29         standard camlibs, gcc, no ltdl, EXIF
libgphoto2_port 0.12.0         iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, no ltdl, EXIF, USB, serial without locking

To Reproduce Steps to reproduce the behavior:

• Run gphoto2 --auto-detect
• Run gphoto2 --list-files. I see this: https://gist.github.com/corsinpfister/cdf5c9717ba0d6f3d48e94da8c3718ad . There are three (large) video files that are reported as being of size 0 KB. Debug logs: https://gist.github.com/corsinpfister/8e5426e00d50300d131b81788bdcefe9
• Copy files with gphoto2 --get-all-files (debug logs are 75 million lines, cannot paste anywhere)
• Observe that the "copied" files MVI_1961.MP4, MVI_1962.MP4, MVI_1963.MP4are empty

[adlerweb]

This also affects M6 Mark II and probably all cameras using a Canons PowerShot OS based system. I tested with a few (externally trimmed) files, 4246050012 Byte is fine while 4321906680 Byte is shown as 0 Byte. As far as I can tell, the protocol used officially only supports size as 32Bit-value resulting in a limit of 2³² = 4294967296 Byte / 4194304 kB / 4096 MB / 4 GB. So officially files >=4GB can't be transferred. As this is a limitation of the protocol and not gphoto2 it also affects other software (e.g. native explorer on Windows 10). Canon itself seems to have a custom protocol extension or an alternate way of accessing files, allowing specialized software like EOS utility to transfer larger files, however as this is closed source it'll probably be hard to figure out how this works. If someone wants to get their hands dirty I can probably provide a USB protocol capture of an EOS utility session.

[outdoorbits]

What's the system type of your destination device? Have you tried to use ext4 Linux filesystem?

[adlerweb]

What's the system type of your destination device? Have you tried to use ext4 Linux filesystem?

In my case arch with latest gphoto2 and btrfs on target. As --list-files already reports an incorrect size, the destination device shouldn't be relevant.

gphoto2         2.5.28         gcc, popt(m), exif, no cdk, no aa, jpeg, readline
libgphoto2      2.5.30         standard camlibs, gcc, no ltdl, EXIF
libgphoto2_port 0.12.1         iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, no ltdl, EXIF, USB, serial without locking

[heyakyra]

This affects the Canon EOS R5, and it is insanely destructive behavior.

Hours of footage were lost because when moving files onto an editing station, it simply moved seemingly-empty files. It would be better to somehow lock the files and prevent the files from being deleted, or maybe just not show them at all.

[corsinpfister]

Hours of footage were lost because when moving files onto an editing station, it simply moved seemingly-empty files. It would be better to somehow lock the files and prevent the files from being deleted, or maybe just not show them at all.

In my case, no files were deleted on the card. I could just use a card reader to fetch the files instead.

[heyakyra]

Yes, if you start with a card reader you are safe. That has nothing to do with how dangerous it is to report the files as 0 bytes.

The files show up as 0 bytes, so this means that a move operation (a cut & paste) means that a 0 byte file gets copied over "successfully" so then the real file gets deleted.