I have several audio devices (car radio, portable radio, MP3 player) that take SD cards and USB sticks with a FAT file system on it. Because these devices have limited intelligence they do not sort filenames on the FAT FS by name but merely play them in the order in which they have been copied to the SD card. In MS DOS and MS Windows this was not a problem; using a simple utility that sorted files alphabetically and then copied them across in that order did the trick. However, on Linux the files copied from the ext4 file system do not end up on the FAT FS in the same order as in which they were read and copied across, presumably because there is a buffering mechanism in the way which improves efficiency but does not worry too much about the physical order in which the files end up on the target device. I have also tried to use Windows in a Virtual Box VM but still the files end up being written in a different order than the one they were read from the Linux file system. Is there a way (short of copying them across manually one by one and waiting for all write buffers to be flushed) to ensure that files end up on the FAT SD target in the order in which they were read from the ext4 file system?

I've got an SD card used for booting a Beaglebone Black. I was having problems booting from the card, or any card for that matter that I created, and I finally tracked down the problem to a disagreement in the number of sectors in the boot partition. What I mean is, dumping the MBR with dd and checking the first partition entry, the Number of sectors in partition gives 0x40000. This is also what e.g. GParted reports. Then, dumping the FAT16 boot partition, the Large number of sectors is only 0x3fff8. This is a difference of 8, which happens to also be the number of hidden sectors reported by the partition (despite being at offset 2048). But why? The boot ROM seems to be throwing its error because the two numbers don't agree, and I didn't think hidden sectors were even considered in the vast majority of cases, let alone when determining the number of sectors. What gives?

I'm struggling to create a FAT-formatted a disk image that can store a file of known size. In this case, a 1 GiB file. For example:

# Create a file that's 1 GiB in size.
dd if=/dev/zero iflag=count_bytes of=./large-file bs=1M count=1G
# Measure file size in KiB.
LARGE_FILE_SIZE_KIB="$(du --summarize --block-size=1024 large-file | cut --fields 1)"
# Create a FAT-formatted disk image.
mkfs.vfat -vv -C ./disk.img "${LARGE_FILE_SIZE_KIB}"
# Mount disk image using a loopback device.
mount -o loop ./disk.img /mnt
# Copy the large file to the disk image.
cp --archive ./large-file /mnt

The script fails with the following output:

++ dd if=/dev/zero iflag=count_bytes of=./large-file bs=1M count=1G
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 39.6962 s, 27.0 MB/s
+++ du --summarize --block-size=1024 large-file
+++ cut --fields 1
++ LARGE_FILE_SIZE_KIB=1048580
++ mkfs.vfat -vv -C ./disk.img 1048580
mkfs.fat 4.2 (2021-01-31)
Auto-selecting FAT32 for large filesystem
Boot jump code is eb 58
Using 32 reserved sectors
Trying with 8 sectors/cluster:
Trying FAT32: #clu=261627, fatlen=2048, maxclu=262144, limit=65525/268435446
Using sector 6 as backup boot sector (0 = none)
./disk.img has 64 heads and 63 sectors per track,
hidden sectors 0x0000;
logical sector size is 512,
using 0xf8 media descriptor, with 2097144 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 8 sectors per cluster.
FAT size is 2048 sectors, and provides 261627 clusters.
There are 32 reserved sectors.
Volume ID is f0de10c3, no volume label.
++ mount -o loop ./disk.img /mnt
++ cp --archive ./large-file /mnt
cp: error writing '/mnt/large-file': No space left on device

How do I create a FAT-formatted disk image that's large enough store a file of known size? Resources: - https://linux.die.net/man/1/dd - https://linux.die.net/man/8/mkfs.vfat - https://linux.die.net/man/8/mount - https://linux.die.net/man/1/cp - https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Size_limits #### EDIT 1 My assumption was that mkfs.vfat -C ./disk.img N would create an image that has N KiBs of usable space, but I guess that's not the case. #### EDIT 2 It seems like a dead end to try to calculate exactly how big the disk image needs to be to store a file of known size because of the complexities around FAT sector/cluster size limits. As suggested in the answers, I've settled for adding 20% extra space to the disk image to allow for FAT overhead.

I believe that the FAT32 file system does not support file permissions, however when I do ls -l on a FAT32 partition, ls -l shows that the files have permissions: -rw-r--r-- 1 john john 11 Mar 20 15:43 file1.txt -rw-r--r-- 1 john john 5 Mar 20 15:49 file2.txt Why is ls -l displaying the permissions of files?

How can I change the volume name of a FAT32 filesystem?  I know I can set the volume name when I format the partition with the -n option of mkfs.vfat.  But how to just change the name without formatting? I especially want to be able to use lower and uppercase letters.  In worst case, I can use a Windows tool, but Windows by default transforms all letters to uppercase (but works fine with lowercase letters in volumes created with mkfs.vfat).

I have a flash drive formatted with a FAT32 partition. When I pull it out before unmounting it naturally has the dirty bit set and when I use the flash in a Windows machine, Windows complains that the drive should be repaired. The Linux machine is an embedded device and has no "unmount" in its GUI. But I have SSH access to this machine and I tried to use the command below to clear the dirty bit: root@system:~# fsck.fat -aw /dev/sda1 fsck.fat 4.1 (2017-01-24) 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Automatically removing dirty bit. Performing changes. /dev/sda1: 4 files, 4/261376 clusters Then I remove the drive (still no unmount) and when I plug it back in a Windows system it still shows the drive should repaired message. So the question is, why fsck does not actually clear the dirty bit? Is there any way to prevent or clear the drty bit so plugging out the drive without a proper unmount doesnt trigger the dirty bit? The reason: I want to have a script or service to perform fsck to clear dirty bit as soon as a drive is mounted. I mean I want the device not to set the dirty bit at all or clear it as soon as a drive is inserted. Because the user has no way of asking the system to perform the unmount

I can't seem to figure how to mount an old 2GB sd card I had lying around from years ago. I forgot what I had on it... Using Debian 11 with KDE 5.20.5 * It's not recognized or mounted when insterted (other cards are, after restarting Dolphin several times, apparently a kde bug...) * When trying to mount manually (also tried with

-t vfat/exfat

):

sudo mount /dev/mmcblk0p1 /mnt/sdcard/
    mount: /mnt/sdcard: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1, missing codepage or helper program, or other error.

* parted output:

Warning: Unable to open /dev/mmcblk0 read-write (Read-only file system). /dev/mmcblk0 has been opened read-only.
    Model: SD 00000 (sd/mmc)                                                  
    Disk /dev/mmcblk0: 2003MB
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos
    Disk Flags: 
    
    Number  Start   End     Size    Type     File system  Flags
     1      66.0kB  2003MB  2003MB  primary

* made a backup with

, that worked, now I have 2GB file on my hdd. * Also tried mkfs.vfat and mkfs.exfat, both complain thye can't open since it's read-only file system *

[1238558.491514] mmc0: new high speed SD card at address 0002
    [1238558.492101] mmcblk0: mmc0:0002 00000 1.87 GiB (ro)
    [1238558.509775]  mmcblk0: p1
    [1239085.062158] exFAT-fs (mmcblk0p1): invalid boot record signature
    [1239085.062168] exFAT-fs (mmcblk0p1): failed to read boot sector
    [1239085.062172] exFAT-fs (mmcblk0p1): failed to recognize exfat type

* tried

:

sudo fsck.fat -n /dev/mmcblk0p1
    fsck.fat 4.2 (2021-01-31)
    Logical sector size (7 bytes) is not a multiple of the physical sector size.

Out of curiosity, is this possible nowadays? I remember some old Slackware versions did support FAT root partition but I am not sure if this is possible with modern kernels and if there are any distros offering such an option. I am interested in pure DOS FAT (without long names support), VFAT 16/32 and exFAT. PS: Don't tell me I shouldn't, I am not going to use this in production unless necessary :-)

I've successfully installed u-boot and linux kernel on STM32F469-disco board but I still don't have a rootfs. my board has 16MB RAM and 16MB FLASH storage and 32GB SDCARD and the CPU core of it is ARM Cortex-M4 32bit processor. I want to know can I just copy my busybox rootfs to a fat32 partition and expect the linux kernel to read it? when I try to copy it to an NTFS partition it throws this error:

PS C:\Users\mahya> copy -r z:\home\mahyar1284\my_projects\buildroot\buildroot-2020.08\output\target\ c:\users\mahya\desktop\target
Copy-Item: The name of the file cannot be resolved by the system. : 'Z:\home\mahyar1284\my_projects\buildroot\buildroot-2020.08\output\target\linuxrc'

--- *UPDATE* tried it with tar command:

C:\Users\mahya>tar -cf -r z:\home\mahyar1284\my_projects\buildroot\buildroot-2020.08\output\target\*
tar: Couldn't open z:/home/mahyar1284/my_projects/buildroot/buildroot-2020.08/output/target/linuxrc: Invalid argument
tar: Error exit delayed from previous errors.

I'm trying to understand which FAT based filesystems my Real Time 2.6 Linux supports. I have tried 3 things: 1. /proc/filesystems shows vfat among others non-relevant for the question (like ext2, etc) 2. /proc/config.gz shows:

# DOS/FAT/NT Filesystems
    #
    CONFIG_FAT_FS=y
    CONFIG_MSDOS_FS=y
    CONFIG_VFAT_FS=y
    CONFIG_FAT_DEFAULT_CODEPAGE=437
    CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
    # CONFIG_NTFS_FS is not set

3. Commands like ls /lib/modules/$(uname -r)/kernel/fs show nothing as .../fs folder doesn't exist. So, looking at this, is safe to asume that FAT and VFAT are supported, but what about FAT32 or exFAT? It's not explicitly specified. How can I know?

I am trying to import contacts from micro-SD to (non Android) Nokia phone. So I first exported current contacts on micro-SD card in hope that i will be able to modify the exported file and then import it. Exported file type is Nokia backup file .NBF. it seem it is actually an ordinary zip file. I can unzip exported .NBF file and modify it (contacts are stored in .vcf - vcard). However when I zip it and try to import it the phone says file is corrupted. i checked zip files with zipinfo: Unmodified file:

$ zipinfo Backup001.NBF
Archive:  Backup001.NBF
Zip file size: 3031 bytes, number of entries: 10
-rw-a--     0.0 fat     1160 b- stor 20-Mar-30 11:31 predefhiddenfolder/predefisasettings/usersettings/user_settings.wbxml
dr-x-hs     0.0 fat        0 b- stor 10-Jan-01 00:00 predefhiddenfolder/predefisasettings/usersettings
dr-xahs     0.0 fat        0 b- stor 07-Jan-01 00:00 predefhiddenfolder/predefisasettings
dr-xahs     0.0 fat        0 b- stor 07-Jan-01 00:00 predefhiddenfolder
-rw-a--     0.0 fat      214 b- defN 20-Mar-30 11:31 predefhiddenfolder/backup/WIP/F01
drwxa--     0.0 fat        0 b- defN 20-Mar-30 11:31 predefhiddenfolder/backup/WIP
drwxa--     0.0 fat        0 b- defN 10-Jan-01 00:00 predefhiddenfolder/backup
-rw-a--     0.0 fat      256 b- defN 20-Mar-30 11:31 predefhiddenfolder/backup/WIP/32/contacts/1.vcf
drwxa--     0.0 fat        0 b- defN 20-Mar-30 11:31 predefhiddenfolder/backup/WIP/32/contacts
drwxa--     0.0 fat        0 b- defN 20-Mar-30 11:31 predefhiddenfolder/backup/WIP/32
10 files, 1630 bytes uncompressed, 1409 bytes compressed:  13.6%

then i modify 1.vcf and update Backup001.NBF with: zip Backup001.NBF -f -r predefhiddenfolder/backup/WIP/32/contacts/1.vcf Modified:

$ zipinfo Backup001.NBF
Archive:  Backup001.NBF
Zip file size: 2958 bytes, number of entries: 10
-rw-a--     0.0 fat     1160 b- stor 20-Mar-30 11:31 predefhiddenfolder/predefisasettings/usersettings/user_settings.wbxml
dr-x-hs     0.0 fat        0 b- stor 10-Jan-01 00:00 predefhiddenfolder/predefisasettings/usersettings
dr-xahs     0.0 fat        0 b- stor 07-Jan-01 00:00 predefhiddenfolder/predefisasettings
dr-xahs     0.0 fat        0 b- stor 07-Jan-01 00:00 predefhiddenfolder
-rw-a--     0.0 fat      214 b- defN 20-Mar-30 11:31 predefhiddenfolder/backup/WIP/F01
drwxa--     0.0 fat        0 b- defN 20-Mar-30 11:31 predefhiddenfolder/backup/WIP
drwxa--     0.0 fat        0 b- defN 10-Jan-01 00:00 predefhiddenfolder/backup
-rw-r--r--  3.0 unx      208 tx defN 20-Apr-03 01:04 predefhiddenfolder/backup/WIP/32/contacts/1.vcf
drwxa--     0.0 fat        0 b- defN 20-Mar-30 11:31 predefhiddenfolder/backup/WIP/32/contacts
drwxa--     0.0 fat        0 b- defN 20-Mar-30 11:31 predefhiddenfolder/backup/WIP/32
10 files, 1582 bytes uncompressed, 1366 bytes compressed:  13.7%

in this line: -rw-r--r-- 3.0 unx 208 tx defN 20-Apr-03 01:04 predefhiddenfolder/backup/WIP/32/contacts/1.vcf it says that format is 3.0 unx. is there any way to zip it so format will be 0.0 fat? Edit: added some clarification Edit: I tried using -k flag as sugessted by @FennecTECH it looks better but still doesn't work.

$ zipinfo Backup000.NBF
Archive:  Backup000.NBF
Zip file size: 2501 bytes, number of entries: 10
drwx---     2.0 fat        0 bx stor 20-Apr-03 00:37 PREDEFHI/
drwx---     2.0 fat        0 bx stor 20-Apr-03 00:36 PREDEFHI/PREDEFIS/
drwx---     2.0 fat        0 bx stor 20-Apr-03 00:36 PREDEFHI/PREDEFIS/USERSETT/
-rw----     2.0 fat     1160 bx defN 20-Mar-30 11:31 PREDEFHI/PREDEFIS/USERSETT/USER_SET.WBX
drwx---     2.0 fat        0 bx stor 20-Apr-03 00:37 PREDEFHI/BACKUP/
drwx---     2.0 fat        0 bx stor 20-Apr-03 00:37 PREDEFHI/BACKUP/WIP/
drwx---     2.0 fat        0 bx stor 20-Apr-03 00:37 PREDEFHI/BACKUP/WIP/32/
drwx---     2.0 fat        0 bx stor 20-Apr-03 01:04 PREDEFHI/BACKUP/WIP/32/CONTACTS/
-rw----     2.0 fat      208 tx defN 20-Apr-03 01:04 PREDEFHI/BACKUP/WIP/32/CONTACTS/1.VCF
-rw----     2.0 fat      214 bx defN 20-Mar-30 11:31 PREDEFHI/BACKUP/WIP/F01

similar question that didn't solve the problem: https://stackoverflow.com/questions/15033646/compression-method-for-xlsx-with-7z

Just encountered a problem: when rebooting a Linux system, timestamps of all files in the mounted VFAT filesystem are shown in the incorrect timezone. It seems like a device starts thinking that its local time is in UTC, so it displays all timestamps with the shift. Steps to reproduce: - Create some small FAT-formatted image: dd if=/dev/zero of=small.img bs=1M seek=1 count=0 mkfs.vfat small.img - Mount this image locally: mount -t vfat -o umask=0022,gid=1001,uid=1001 small.img mnt - Set the timezone to some non-UTC one; - Create a file in the mounted filesystem (ie. touch mnt/newfile) - Observe the file modification/change timestamps: they are correct, concerning the currently set one: stat mnt/newfile

File: mnt/newfile
    Size: 0         	Blocks: 0          IO Block: 16384  regular empty file
    Device: 700h/1792d	Inode: 40          Links: 1
    Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2021-03-22 12:19:56.000000000 +0100
    Modify: 2021-03-22 12:19:56.000000000 +0100
    Change: 2021-03-22 12:19:56.000000000 +0100
    Birth: -

timedatectl

Local time: Mon 2021-03-22 12:19:07 CET
    Universal time: Mon 2021-03-22 11:19:07 UTC
    RTC time: Mon 2021-03-22 11:19:07
    Time zone: Europe/Vienna (CET, +0100)
    System clock synchronized: yes
    NTP service: active
    RTC in local TZ: no

- Unmount the filesystem, to check if anything has been changed with the remount: umount mnt; mount -t vfat -o umask=0022,gid=1001,uid=1001 small.img mnt; stat mnt/newfile

File: mnt/newfile
   Size: 0         	Blocks: 0          IO Block: 16384  regular empty file
   Device: 700h/1792d	Inode: 64          Links: 1
   Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
   Access: 2021-03-22 00:00:00.000000000 +0100
   Modify: 2021-03-22 12:19:56.000000000 +0100
   Change: 2021-03-22 12:19:56.000000000 +0100
   Birth: -

- Reboot the system; - Mount the image once more, have a look at the created file's timestamps:

File: mnt/newfile
    Size: 0         	Blocks: 0          IO Block: 16384  regular empty file
    Device: 700h/1792d	Inode: 26          Links: 1
    Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2021-03-22 01:00:00.000000000 +0100
    Modify: 2021-03-22 13:19:56.000000000 +0100
    Change: 2021-03-22 13:19:56.000000000 +0100
    Birth: -

It can be clearly observable, that the time is shifted forward by 1 hour (12:10 to 13:19), while the timezone is shown the same - +0100. Looks like mount now thinks that the file timestamps were recorded in UTC, so it tries to display them with the "correct" shift. To check the validity of the previous statement, let's remount the same filesystem with the tz=UTC option explicitly: mount -t vfat -o umask=0022,gid=1001,uid=1001,tz=UTC small.img mnt; stat mnt/newfile

File: mnt/newfile
   Size: 0         	Blocks: 0          IO Block: 16384  regular empty file
   Device: 700h/1792d	Inode: 50          Links: 1
   Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
   Access: 2021-03-22 01:00:00.000000000 +0100
   Modify: 2021-03-22 13:19:56.000000000 +0100
   Change: 2021-03-22 13:19:56.000000000 +0100
   Birth: -

Even though the system's timezone is CET indeed: date

Mon Mar 22 12:26:42 CET 2021

P.S. https://stackoverflow.com/questions/10068855/how-do-i-get-the-correct-modified-datetime-of-a-fat32-file-regardless-of-timezo is not an answer to this question, since I can't get from it, why is this change seen right after reboot of the machine and not after a remount? If vfat stores timestamps in local time, why does mount after rebooting assumes that the timestamps are in UTC rather than local time?

If I put a USB memory stick (FAT formatted) into a Windows PC, then unplug it without "ejecting" it, then put it in again, Windows is okay with that, without giving any warning about it "possibly having problems". But if I do the same with Linux (e.g. Ubuntu 15.04), then after inserting it the second time, I get warning messages in the log like: FAT-fs (sdf1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. And if I subsequently put it in a Windows PC, I get a message popping up prompting me to check it for errors. Why is Linux handling of the FAT "dirty" flag so basic? I would have thought it would be better to only set the "dirty" flag if it really is potentially "dirty" -- e.g. something like: * Set the "dirty" flag when a file is written. * Clear the "dirty" flag when: * all written files are closed, and/or * the write cache is written out to disk, * and of course, when the disk is unmounted. It would be nice if there was at least some mount option to operate in that mode, to reduce the chance of users getting "dirty" flag false alarms for merely plugging and unplugging a removable device, even though nothing was actually written.

Is there a way to create a FAT32 filesystem containing a set of files, without needing to mount it or have root access? I am developing a software application for an old operating system as a hobby, and as part of the build process I would like to package up some source files into a FAT32 disk image, then launch QEMU to boot the image and run an old compiler in it. Afterwards I would like to extract the compiled file out of the FAT32 disk image. I can create the filesystem with mkfs.vfat, however the only way I know of to get files into and out of the image is to mount it, which typically requires root access and is not conducive to being embedded in a build process. Ideally I am after something like the zip and unzip utilities, only instead of creating/extracting .zip files, it would create and extract disk images in FAT16 or FAT32 format. Does anything like this exist? The only things I can find online all involve mounting the disk image.

I've noticed that when I mount a FAT filesystem on Linux, all of the files have their executable permissions set. Why is this? There's almost no chance that you can or want to directly execute any program found on a FAT file system, and having the executable bit implicitly set for all files seems annoying to me. I understand that FAT (and other filesystems as well) have no mode bits, and so the 777 mode I'm seeing on files is just simulated by the filesystem driver under Unix. My question is why 777 instead of 666?

How to run Linux script e.g configure etc, in FAT (or alike raw) filesystem ? $ sudo chmod -R 777 . $ ./configure bash: ./configure: Permission denied How to solve ?

I am nod able to install mono development even after i gave apt get update. My system is asking for Mono depends on =6.10.0.104-0-xamarin16+debian10b1 Its also asking Hit https://download.mono-project.com/rep/debian vs-buster Inrelease

Each time I unmount the filesystem of my SD card that I use on my DSLR, I have to wait several seconds for umount command to finish — even if I've just mounted the FS as read-only and immediately unmount it. The mount command is simple:

mount /dev/sdd1 /mnt/tmp -oro

I've tried setting vm.block_dump=1 to see what's going on, and here's what I saw when I issued umount /mnt/tmp:

$ tail -n9999 /var/log/kern.log | grep sdd1

Jul  7 16:56:42 IntegralH kernel: [143924.204781] umount(16203): READ block 1635 on sdd1 (1 sectors)
Jul  7 16:56:42 IntegralH kernel: [143924.210786] umount(16203): READ block 1636 on sdd1 (1 sectors)
Jul  7 16:56:42 IntegralH kernel: [143924.216805] umount(16203): READ block 1637 on sdd1 (1 sectors)
Jul  7 16:56:42 IntegralH kernel: [143924.222841] umount(16203): READ block 1638 on sdd1 (1 sectors)
Jul  7 16:56:42 IntegralH kernel: [143924.228867] umount(16203): READ block 1639 on sdd1 (1 sectors)

Jul  7 16:57:34 IntegralH kernel: [143976.105848] umount(16203): READ block 9006 on sdd1 (1 sectors)
Jul  7 16:57:34 IntegralH kernel: [143976.111932] umount(16203): READ block 9007 on sdd1 (1 sectors)
Jul  7 16:57:34 IntegralH kernel: [143976.117915] umount(16203): READ block 9008 on sdd1 (1 sectors)

The skipped part after block 1639 consists of single-block reads of every block between 1639 and 9006. To make sure that my suspicion is correct, I've checked the first sector of the FS:

$ sudo head -c 40 /dev/sdd1 | xxd -g1
0000000: eb 00 90 43 41 4e 4f 4e 45 4f 53 00 02 40 62 06  ...CANONEOS..@b.
0000010: 02 00 00 00 00 f8 00 00 3f 00 ff 00 00 20 00 00  ........?.... ..
0000020: 00 18 9a 03 cf 1c 00 00                          ........

You can see that the number of reserved sectors (which denotes the first sector of the FAT; 2 bytes at offset 0x0E), is 0x662, or 1634. And the size of the FAT (4 bytes at offset 0x24) is 0x1ccf, or 7375=9008+1-1634. I.e. the driver reads the whole FAT except its first sector. I wonder now, why does the driver need to read the whole FAT simply to unmount the filesystem? And how can I avoid this time-consuming operation?

What is the best way to defragment a FAT filesystem when running Linux/Unix (on usb stick for instance)? - Copy all content elsewhere, format, copy back again? - Use FreeDOS defrag utility , in a KVM command? - Boot with Partition Logic ? - other?

**Log**: ~$ cp -r folder /media/usr/media-name/ cp: error writing '/location-to-file/file.zip': File too large **Question**: How to copy large files/folders to media in Linux? ________________ ### Excess Details 500 GB Sandisk Drive (recently formatted to FAT using GNOME Disks) Folder of under 20 GB