0

I have this file on disk:

$ ls -lh /path/to/some.mkv -rwxr-xr-x 1 enrico enrico 7.4G Dec 17 18:54 /path/to/some.mkv

so it's less than 8 gigabytes, but when I try to copy it on a 30GiB flash drive, I get this error:

cp: error writing '/path/to/some.mkv': File too large

Here's the drive:

$ sudo fdisk -l | tail -n 16 Disk /dev/sdc: 29.3 GiB, 31457280000 bytes, 61440000 sectors Disk model: USB DISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x6f20736b Device Boot Start End Sectors Size Id Type /dev/sdc1 778135908 1919645538 1141509631 544.3G 72 unknown /dev/sdc2 168689522 2104717761 1936028240 923.2G 65 Novell Netware 386 /dev/sdc3 1869881465 3805909656 1936028192 923.2G 79 unknown /dev/sdc4 2885681152 2885736650 55499 27.1M d unknown Partition table entries are not in disk order. $ sudo mount /dev/sdc /mnt/foo $ cd /mnt/foo $ df . -h Filesystem Size Used Avail Use% Mounted on /dev/sdc 30G 16K 30G 1% /mnt/foo
Improve this question
5
  • 3
    I'm a bit confused by what you've posted. The drive is partitioned, but you successfully mounted the device as a whole and not one of the partitions? Can you do a mount | grep sdc, edit your question, and add the output? Commented Jan 3 at 20:10
  • 2
    @AndyDalton There is a filesystem on the entire device and the alleged partition table is just an interpretation of several bytes that normally contain a partition table, but here they belong to the actual filesystem and as a partition table they do not make sense. This is why the entries are so insane (2400G inside a 30G disk? Come on!). Trying to mess with them so the "partition table" looks empty may break the actual filesystem, they should stay. There is nothing to fix though. Compare to this answer where a similar situation happens with NTFS. Commented Jan 3 at 20:53
  • 1
    BTW, such confusion is one of the reasons it's better not to create a filesystem on the whole device. Commented Jan 3 at 20:55
  • It is unlikely that fdisk is showing any reliable information. In addition to the impossible sizes, the sectors of sdc1 are entirely contained within the sectors of sdc2 and there is a huge overlap between the sectors of sdc2 and sdc3. I doubt sdc2 is actually formatted as Novell Netware. Most likely fdisk just took some garbage from where the partition table should be and interpreted that way. Commented Jan 3 at 22:07
  • Normally Apple use gpt not MBR(msdos) for partitions. The output like you have is often from the creation of a live installer in hybrid DVD/flash drive mode. It then does not have a standard partition table & random data in partition table. Reset USB flash that was dd'd to make it usable again, reuse askubuntu.com/questions/939230/… & help.ubuntu.com/community/mkusb#Re-use_the_pendrive & Commented Jan 6 at 16:36

2 Answers 2

Reset to default
4

My answer here will assume that whatever you have mounted, the filesystem type is fat32. In that case, there's a maximum file size of 4G (i.e., no single file can be greater than 4G).

https://en.wikipedia.org/wiki/File_Allocation_Table (See Fat32)

If you really have /dev/sdc2 mounted and, based on your fdisk output, that's a NetWare filesystem, that too has a maximum file size of 4G.

https://en.wikipedia.org/wiki/NetWare_File_System

Improve this answer
0
0

This serves as an addition to the accepted answer and also as a potential source of possibly important facts, which were untold by the OP. This should normally not happen. You shall not intentionally redact / hide / manually edit any command outputs like your fdisk, for any reasons other than hiding some sensitive information like serial numbers, for example.

Today, I needed to restore some of my oldest audio collection,.. no, I did not backup my MP3s. So, I remembered I had some old Apple iPod (4GB). I plugged it into the USB, and voila, I see some very similar, and particularly strange, partitioning like the OP posted:

# fdisk -l /dev/sdb Disk /dev/sdb: 3,78 GiB, 4055885824 bytes, 1980413 sectors Disk model: iPod Units: sectors of 1 * 2048 = 2048 bytes Sector size (logical/physical): 2048 bytes / 2048 bytes I/O size (minimum/optimal): 2048 bytes / 2048 bytes Disklabel type: dos Disk identifier: 0x6f20736b Device Boot Start End Sectors Size Id Type /dev/sdb1 778135908 1919645538 1141509631 2,1T 72 unknown /dev/sdb2 168689522 2104717761 1936028240 3,6T 65 Novell Netware 386 /dev/sdb3 1869881465 3805909656 1936028192 3,6T 79 unknown /dev/sdb4 2885681152 2885736650 55499 108,4M d unknown Partition table entries are not in disk order.

You see the resemblance?!

Now, how it mounts:

# mount -v | grep -i sdb /dev/sdb on /media/vlastimil/18ED-9712 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Intereestingly, as you can see, the primary file system resides on the device itself and not in those partitions we can see with fdisk. We could argue, that such an engineering is wrong, but Apple won't change, I suppose, so there is nothing to gain.

One example, where it would really mess things up, may be fdisk, and I mean you really must read the warning:

# fdisk /dev/sdb Welcome to fdisk (util-linux 2.39.3). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. The device contains 'vfat' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details. Command (m for help): p Disk /dev/sdb: 3,78 GiB, 4055885824 bytes, 1980413 sectors Disk model: iPod Units: sectors of 1 * 2048 = 2048 bytes Sector size (logical/physical): 2048 bytes / 2048 bytes I/O size (minimum/optimal): 2048 bytes / 2048 bytes Disklabel type: dos Disk identifier: 0x6f20736b Device Boot Start End Sectors Size Id Type /dev/sdb1 778135908 1919645538 1141509631 2,1T 72 unknown /dev/sdb2 168689522 2104717761 1936028240 3,6T 65 Novell Netware 386 /dev/sdb3 1869881465 3805909656 1936028192 3,6T 79 unknown /dev/sdb4 2885681152 2885736650 55499 108,4M d unknown Partition table entries are not in disk order. Command (m for help): q

Let me stress it:

The device contains 'vfat' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.

Be sure not to hit w there! :)

When unmounted, running fsck is not dangerous:

# fsck -fvy /dev/sdb fsck from util-linux 2.39.3 fsck.fat 4.2 (2021-01-31) Checking we can access the last sector of the filesystem There are differences between boot sector and its backup. This is mostly harmless. Differences: (offset:original/backup) 65:01/00 Not automatically fixing this. Boot sector contents: System ID "MSDOS5.0" Media byte 0xf8 (hard disk) 2048 bytes per logical sector 4096 bytes per cluster 236 reserved sectors First FAT starts at byte 483328 (sector 236) 2 FATs, 32 bit entries 3952640 bytes per FAT (= 1930 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 8388608 (sector 4096) 988158 data clusters (4047495168 bytes) 63 sectors/track, 255 heads 0 hidden sectors 1980413 sectors total Volume label 'UªIVATEL -' stored in root directory is not valid. Auto-removing label. Reclaiming unconnected clusters. Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Automatically removing dirty bit. Checking free cluster summary. *** Filesystem was changed *** Writing changes. /dev/sdb: 122 files, 44508/988158 clusters

I also went on checking the system log, attaching for completeness:

[Sun Jan 5 20:19:47 2025] usb 1-2: new high-speed USB device number 10 using xhci_hcd [Sun Jan 5 20:19:47 2025] usb 1-2: New USB device found, idVendor=05ac, idProduct=1302, bcdDevice= 0.01 [Sun Jan 5 20:19:47 2025] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Sun Jan 5 20:19:47 2025] usb 1-2: Product: iPod [Sun Jan 5 20:19:47 2025] usb 1-2: Manufacturer: Apple Inc. [Sun Jan 5 20:19:47 2025] usb 1-2: SerialNumber: <- SN removed -> [Sun Jan 5 20:19:47 2025] usb-storage 1-2:1.0: USB Mass Storage device detected [Sun Jan 5 20:19:47 2025] scsi host2: usb-storage 1-2:1.0 [Sun Jan 5 20:19:47 2025] usbcore: registered new interface driver usb-storage [Sun Jan 5 20:19:47 2025] usbcore: registered new interface driver uas [Sun Jan 5 20:19:47 2025] usbcore: registered new device driver apple-mfi-fastcharge [Sun Jan 5 20:19:48 2025] scsi 2:0:0:0: Direct-Access Apple iPod 2.70 PQ: 0 ANSI: 2 [Sun Jan 5 20:19:48 2025] sd 2:0:0:0: Attached scsi generic sg1 type 0 [Sun Jan 5 20:19:48 2025] sd 2:0:0:0: [sdb] 1980413 2048-byte logical blocks: (4.06 GB/3.78 GiB) [Sun Jan 5 20:19:48 2025] sd 2:0:0:0: [sdb] Write Protect is off [Sun Jan 5 20:19:48 2025] sd 2:0:0:0: [sdb] Mode Sense: 6e 00 00 08 [Sun Jan 5 20:19:48 2025] sd 2:0:0:0: [sdb] Incomplete mode parameter data [Sun Jan 5 20:19:48 2025] sd 2:0:0:0: [sdb] Assuming drive cache: write through [Sun Jan 5 20:19:48 2025] sdb: [Sun Jan 5 20:19:48 2025] sd 2:0:0:0: [sdb] Attached SCSI removable disk [Sun Jan 5 20:19:48 2025] FAT-fs (sdb): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

My iPod supports only FAT32 as per from the following file:

/media/vlastimil/18ED-9712/iPod_Control/Device/SysInfoExtended

where an excerpt states the file system:

<key>VolumeFormat</key><string>FAT32</string>

FAT32 on Wikipedia states, as was already said, I quote:

The maximal possible size for a file on a FAT32 volume is 4 GB minus 1 byte or more exactly 232 − 1 bytes.

Improve this answer
2
  • The flash drive of my question is not an Apple product, to the best of my knowledge. It is labelled with the name of a company but that's not Apple, nor a company making hardware. It's like you go to a conference organized by Boeing, and they'll give you a flash drive with the Boeing logo. Who's the producer of the flash drive, I don't know, but it could be Apple as much as it could be any one else. Commented Jan 6 at 6:57
  • @Enlico Ah, I see. I will delete the Conclusion then. Have a good day, cheers! Done. Commented Jan 6 at 8:04

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.