exfatprogs / exfatprogs Goto Github PK

In function bytes_to_human_readable, if bytes > 1024PB, the variable named i will be 6 and in “snprintf(buf, sizeof(buf), "%u.%02u %s", quoti, remain, units[i]);”，function will access units[6] . This will cause Out-of-Bounds Accesses.

Please consider adding a separate tool or extending the label tool to change the volume serial number of an exFAT file system (offset 0x64/100 in main boot sector).
For FAT under Linux one can use mlabel -N 12345678 -i /dev/sdb1.

I have a camera that will format into exfat if the card is sufficiently large. The card formatted-in-camera will mount okay on my gentoo PC but when I try to give the card a label, the FS breaks.

Steps to reproduce

Camera in question: Olympus OM-D E-M1 Mark 2, firmware 3.6.

1. Take a suitably large card so that the camera will default to an
   exfat formatting (64 GiB)
2. Format it in-camera (and take a snapshot on it)
3. mount it on PC.

      $ mount /dev/sdg1 -t exfat sdhc
      $ tree sdhc
      sdhc
      ├── ALBM
      │   └── ALB67ZZ7.BIN
      └── DCIM
          └── 100OLYMP
              └── P9120001.ORF

      3 directories, 2 files

4. Umount it.
5. (make an image of the block device using bzip2 at this point)
6. Give it a label using the following invocation:

      $ tune.exfat -L 'OLY' '/dev/sdg1'
      exfatprogs version : 1.1.3
      new label: OLY

7. Try mounting this using kernel exfat support

     $ mount /dev/sdg1 -t exfat /media/sdhc

     mount: /media/sdhc: wrong fs type, bad option, bad superblock on
     /dev/sdg1, missing codepage or helper program, or other error

dmesg messages related to this incident:

     [Mon Sep 12 13:51:35 2022] exFAT-fs (sdg1): failed to load alloc-bitmap
     [Mon Sep 12 13:51:35 2022] exFAT-fs (sdg1): failed to recognize exfat type

Trying to mount this via FUSE-exfat version 1.3.0 I get a similar
error message.

     $ mount /dev/sdg1 -t exfat-fuse /media/sdhc 
     FUSE exfat 1.3.0
     ERROR: clusters bitmap is not found.

8. The camera doesn't recognize the FS either.
9. I formatted it on PC:

     $ mkfs.exfat -L OLY /dev/sdg1
     exfatprogs version : 1.1.3
     Creating exFAT filesystem(/dev/sdg1, cluster size=131072)

     Writing volume boot record: done
     Writing backup volume boot record: done
     Fat table creation: done
     Allocation bitmap creation: done
     Upcase table creation: done
     Writing root directory entry: done
     Synchronizing...

     exFAT format complete!

     $ mount /dev/sdg1 /media/sdhc
     FUSE exfat 1.3.0

     $ umount /media/sdhc
     $ 

This way the card seems to be remain readable both in my system and in-camera.

The block device image

It is of a 58-gibibyte FS, 300 megabytes bzip2'd. You can find it here. https://fwwm.us/p/oly_sdcard_before_labeling.img.bz2

I made it of the first allocated partition sdg1 instead of the whole sdg. Making another will take me an hour so let me know if you need it.

Please let me know if you need something else.

Hi,

I observe that mounting an exFAT file system formatted with exfatprogs fails if the underlying device is an Advanced Format, 4K
native HDD. 4K native HDDs report both a physical and logical block size equal to 4 KB.

Below are the properties of a 4Kn disk emulated with QEMU:

$ lsblk --topology /dev/vda
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED       RQ-SIZE  RA WSAME
vda          0   4096      0    4096    4096    1 mq-deadline     256 128    0B

Formatting the device with exfatprogs' mkfs.exfat succeeds. The block sector size is correctly probed as 4096 bytes:

$ sudo mkfs/mkfs.exfat -v /dev/vda
exfatprogs version : 1.1.1
[exfat_get_blk_dev_info: 202] Block device name : /dev/vda
[exfat_get_blk_dev_info: 203] Block device offset : 0
[exfat_get_blk_dev_info: 204] Block device size : 21474836480
[exfat_get_blk_dev_info: 205] Block sector size : 4096
[exfat_get_blk_dev_info: 206] Number of the sectors : 41943040
[exfat_get_blk_dev_info: 208] Number of the clusters : 655360
[exfat_zero_out_disk: 505] zero out written size : 4358144, disk size : 21474836480
Creating exFAT filesystem(/dev/vda, cluster size=32768)

Writing volume boot record: [exfat_setup_boot_sector:  80] Volume Offset(sectors) : 0
[exfat_setup_boot_sector:  82] Volume Length(sectors) : 5242880
[exfat_setup_boot_sector:  84] FAT Offset(sector offset) : 256
[exfat_setup_boot_sector:  86] FAT Length(sectors) : 640
[exfat_setup_boot_sector:  88] Cluster Heap Offset (sector offset) : 1024
[exfat_setup_boot_sector:  90] Cluster Count : 655232
[exfat_setup_boot_sector:  92] Root Cluster (cluster offset) : 6
[exfat_setup_boot_sector:  94] Volume Serial : 0x6ddeb17c
[exfat_setup_boot_sector:  95] Sector Size Bits : 12
[exfat_setup_boot_sector:  97] Sector per Cluster bits : 3
done
Writing backup volume boot record: [exfat_setup_boot_sector:  80] Volume Offset(sectors) : 0
[exfat_setup_boot_sector:  82] Volume Length(sectors) : 5242880
[exfat_setup_boot_sector:  84] FAT Offset(sector offset) : 256
[exfat_setup_boot_sector:  86] FAT Length(sectors) : 640
[exfat_setup_boot_sector:  88] Cluster Heap Offset (sector offset) : 1024
[exfat_setup_boot_sector:  90] Cluster Count : 655232
[exfat_setup_boot_sector:  92] Root Cluster (cluster offset) : 6
[exfat_setup_boot_sector:  94] Volume Serial : 0x6ddeb17c
[exfat_setup_boot_sector:  95] Sector Size Bits : 12
[exfat_setup_boot_sector:  97] Sector per Cluster bits : 3
done
Fat table creation: [exfat_create_fat_table: 296] Total used cluster count : 7
done
Allocation bitmap creation: done
Upcase table creation: done
Writing root directory entry: done
Synchronizing...

exFAT format complete!

However, mounting the exFAT filesystem fails. The Linux kernel reports an Invalid boot checksum error.

$ sudo mount /dev/vda /mnt/
[  262.063000] exFAT-fs (vda): Invalid boot checksum (boot checksum : 0x8455546b, checksum : 0xfedcaae5)
[  262.068991] exFAT-fs (vda): invalid boot region
[  262.071618] exFAT-fs (vda): failed to recognize exfat type
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/vda, missing codepage or helper program, or other error.

Moreover, fsck.exfat reports the same issue:

$ sudo fsck/fsck.exfat /dev/vda
exfatprogs version : 1.1.1
checksum of boot region is not correct. 0x8455546b, but expected 0xfedcaae5
boot region is corrupted. try to restore the region from backup. Fix (y/N)? n

I am going to investigate and will report on my findings later.

I'm seeing this build error here.

  CC       repair.o
fsck.c: In function 'main':
fsck.c:1213:9: error: missing braces around initializer [-Werror=missing-braces]
  struct fsck_user_input ui = {0,};
         ^
fsck.c:1213:9: error: (near initialization for 'ui.ei') [-Werror=missing-braces]
fsck.c: At top level:
ccc

Fsck doesn't manage to correct error.

Master branch

exfatprogs version : 1.0.3
[check_inode: 726] size 4210715009 is greater than cluster heap: /DCIM/100MEDIA/P0580058.MP4
[check_inode: 726] size 4160850480 is greater than cluster heap: /DCIM/100MEDIA/P0580059.MP4
[check_inode: 726] size 4213510884 is greater than cluster heap: /DCIM/100MEDIA/P0590060.MP4
[check_inode: 726] size 4210379928 is greater than cluster heap: /DCIM/100MEDIA/P0600062.MP4
[check_inode: 726] size 4205037059 is greater than cluster heap: /DCIM/100MEDIA/P0600063.MP4
[check_inode: 726] size 4204910218 is greater than cluster heap: /DCIM/100MEDIA/P0600064.MP4
[check_inode: 711] file is empty, but first cluster is 0x518fa: /FCR/mnt/logs/FDR/test_output/fcr-1295.jpeg
[check_inode: 733] empty, but marked as contiguous: /FCR/mnt/logs/FDR/test_output/fcr-1295.jpeg
[check_inode: 711] file is empty, but first cluster is 0x518fe: /FCR/mnt/logs/FDR/test_output/fcr-1296.jpeg
[check_inode: 733] empty, but marked as contiguous: /FCR/mnt/logs/FDR/test_output/fcr-1296.jpeg
/dev/mmcblk0p1: clean

exfat-next

exfatprogs version : 1.0.3
/FCR/mnt/logs/FDR/test_output/fcr-1295.jpeg: first cluster is wrong. Truncate (y/N)? y
empty, but marked as contiguous: /FCR/mnt/logs/FDR/test_output/fcr-1295.jpeg
/FCR/mnt/logs/FDR/test_output/fcr-1295.jpeg: the checksum of a file is wrong. Fix (y/N)? y
corrupted file directory entries.
failed to verify file. -22
failed to check dentries: /FCR/mnt/logs/FDR/test_output
failed to verify directory entries.

exfatprogs version : 1.0.3
empty, but marked as contiguous: /FCR/mnt/logs/FDR/test_output/fcr-1295.jpeg
corrupted file directory entries.
failed to verify file. -22
failed to check dentries: /FCR/mnt/logs/FDR/test_output
failed to verify directory entries.

The fuse fsck don't manage to correct it.

exfatfsck 1.3.0
Checking file system on /dev/mmcblk1p1.
File system version 1.0
Sector size 512 bytes
Cluster size 128 KB
Volume size 119 GB
Used space 41 GB
Available space 79 GB
ERROR: 'fcr-1295.jpeg' is empty but start cluster is 0x518fa.
ERROR: 'fcr-1295.jpeg' is empty but marked as contiguous (0x20).
Totally 7 directories and 79 files.
File system checking finished. ERRORS FOUND: 2, FIXED: 0.

dump.exfat tool should do more than just disk/volume information.

The advantages of exfat filesystem are that (A) it is simple, (B) has huge maxsize limit and (C) has a bit for indicating contiguous-ness allowing for read optimization (D) absence of journaling is better for lifespan of SSD.
The simplicity is a trade off against not having a journal and disk failure tolerance, robustness.

A use case of exfat filesystem is to store large static container files like virtual-disk images, that are seldom resized/moved. They may also be defragmented in the case of hdd (not ssd) as contiguous files.
More importantly, knowing where the used file blocks are helps in case of disaster recovery.

dump.exfat /dev/sdx|/mnt/exfat <arguments> . Following arguments are being suggested
-s in formatted text show only information from superblock(s)
-u in formatted text show comma separated (or line separated) offset ranges of used sectors in increasing order and the file to which the sector range belongs to specified in bytes/blocks/clusters.
-f <filepath> in formatted text show comma separated (or line separated) offset ranges of bytes/blocks/clusters associated with a file
-R <dirpath> in formatted text recursively descend a directory show pathname and comma separated (or line separated) offset ranges of bytes/blocks/clusters associated with contained files (this functionality may also be simulated by using a shell script to loop over output of find command and use -f argument on each file)
-o <bkup_tableflname> in a binary stream output/dump the FAT sectors to a offline backup file

The dump information saved as a periodical (nightly) backup ahead of any disaster, so that in the event disaster happens, it may be used for disaster recovery.
The formatted text dump information will be helpful while using a command like dd during disaster recovery .

dd if=/bad/partition_blockdev of=/good/fs/opath/frag1 bs=512 offset=off1 count=len1 
dd if=/bad/partition_blockdev of=/good/fs/opath/frag2 bs=512 offset=off2 count=len2  
:
dd if=/bad/partition_blockdev of=/good/fs/opath/fragN bs=512 offset=offN count=lenN
dd if=/bad/partition_blockdev of=/good/fs/opath/fragNb bs=1 offset=$((512*(offN+lenN))) count=lenbytes  
cd /good/fs/opath/
cat frag1 frag2 ... fragN fragNb > reconstructed_file

One may then append the fragments / concatenate them together to recover the original file on a new filesystem
Such metadata can be saved on a different disk/partition and will be helpful during disaster recovery.

The following also requires a option parameter feature addition to the mount -t exfat command
Saving a binary dump of the enitire FAT would be used the following way.
dump.exfat /dev/sdx|/mnt/exfat -o <bkup_tableflname>
This could then be used in conjunction with mount.exfat
mount.exfat /dev/sdx /mnt/tmpexfat -o ro,fat=<bkup_tableflname>
This allows using regular cp/dd/ddrescue/filecopy commands to copy data off the corrupted FAT/partition using the offline backup table.

I'm seeing this build error when i attempt to compile exfatprogs.

fsck.c: In function ‘main’:
fsck.c:1053:18: error: ‘node’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     node->parent = dir;
                  ^
fsck.c:861:22: note: ‘node’ was declared here
  struct exfat_inode *node;
                      ^
fsck.c: At top level:

Hi, according to https://github.com/exfatprogs/exfatprogs/releases/tag/1.1.0 we should now be able to recover a corrupted boot region with version 1.1.0

I installed the new version but it won't allow me to select y to fix the boot region. It just assumes N and skips it.

I'm using Arch Linux, using the exfatprogs package version 1.1.0-1

Here is a screenshot of my terminal output when I try to repair the boot region on my external drive:

Hello. I have:

• Fedora 35
• exitprocess v1.1.3
• external USB Hard Drive

In my case USB Hard Drive shared folders via my router. When i mount hard drive to my PC a have not access to my folder:

• If open via file manager - mount point show is empty
• if i do command ls - no it is not possible to access the "Game": there is no such file or directory
  Games is my exists folder which success share via router.
  superuser not helped.

I tryed mount use command:
sudo mount -t exfat /dev/sda1 /media/ex/
or
sudo mount -o rw,users,uid=1000,gid=1000,dmask=000,fmask=000 /dev/sda1 /media/ex/
but does not sense.
In Windows the hard drive work corrected.
fsck.exfat works out correct - no errors.

How fix this problem?

Hi,

I suppose this is a kernel driver bug, but I hope by filing it here it will reach the correct people.

I have formatted a 3TB drive in USB enclosure under Windows 10 21H1 (OS Build 19043.1348) as exFAT.

I try to use it on a Linux device with kernel 5.15.5 and exfatprogs 1.1.3.

Connecting the drive:

[94326.044840] usb-storage 2-1:1.0: USB Mass Storage device detected
[94326.054889] scsi host2: usb-storage 2-1:1.0
[94336.077012] scsi 2:0:0:0: Direct-Access     ATA      WDC WD30PURX-64P 0A80 PQ: 0 ANSI: 6
[94336.078337] sd 2:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
[94336.078524] sd 2:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
[94336.078535] sd 2:0:0:0: [sdb] 4096-byte physical blocks
[94336.079218] sd 2:0:0:0: [sdb] Write Protect is off
[94336.079229] sd 2:0:0:0: [sdb] Mode Sense: 43 00 00 00
[94336.079844] sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[94336.366187]  sdb: sdb1 sdb2
[94336.368370] sd 2:0:0:0: [sdb] Attached SCSI disk

Mounting the drive:

[95338.486473] exFAT-fs (sdb1): invalid boot record signature
[95338.486491] exFAT-fs (sdb1): failed to read boot sector
[95338.486496] exFAT-fs (sdb1): failed to recognize exfat type

exfatprogs utilities:

fsck.exfat -n /dev/sdb1
exfatprogs version : 1.1.3
failed to find exfat file system
boot region is corrupted. try to restore the region from backup. Fix (y/N)? n

tune.exfat -v /dev/sdb1
exfatprogs version : 1.1.3
[exfat_get_blk_dev_info: 202] Block device name : /dev/sdb1
[exfat_get_blk_dev_info: 203] Block device offset : 17408
[exfat_get_blk_dev_info: 204] Block device size : 134217728
[exfat_get_blk_dev_info: 205] Block sector size : 512
[exfat_get_blk_dev_info: 206] Number of the sectors : 262144
[exfat_get_blk_dev_info: 208] Number of the clusters : 32768

dump.exfat /dev/sdb1
exfatprogs version : 1.1.3
bogus sector size bits : 0

Please let me know if you need more information.

There's https://github.com/relan/exfat:

• provides a FUSE driver (not needed in recent versions of the linux kernel)
• doesn't provide a tune utility

And this project (https://github.com/exfatprogs/exfatprogs) which is driven by Samsung, AFAIK:

• uses the native kernel driver
• doesn't provide a labeling utility, for example.

It would be really helpful to see some kind of merger here. It was sort of mentioned in relan/exfat#151

According to the coverity check, if clus < EXFAT_FIRST_CLUSTER in exfat_c2o(), a negative value will be returned, but if a negative value is returned, it will cause an error in exfat_write(). After tracing the code, it was found that the if statement in exfat_c2o() should not have a chance to be true (perhaps I missed something). May I ask if this if statement can be removed? Or is it used to avoid some special situations?

Please add file system usage reporting of unmounted exfat file systems into one of the command line tools. Probably extend tune.exfat -v output.

Note that the Linux kernel exfat implementation, exfat_statfs(), already provides this when the file system is mounted for the statfs(2) call.

All other Linux file system tools provide some way to report total number of blocks / clusters and used or available blocks / clusters.

My particular reason is so that I can make GParted report the usage of unmounted exfat file systems to users.

Thanks,
Mike Fleetwood (GParted Developer)

Hello Namjae Jeon,

I recently read about exfat-utils on reddit, so I landed here. I do not know much else
about the project, which brought me to this question:

• Do you think it would be possible to add a very short paragraph, on the main
  README.md of the project, explaining the main use case or motivation for
  exfat-utils?

Right now I wonder about how exfat-utils fits into the rest of the toolchain
e. g. e2fsprogs, util-linux and so forth. Hope I could explain the reason for my
question here.

Thanks for your time!

hello !

        I compile the code with mips cross compile tool ，but the mkfs.exfat can not work normal !  what' wrong ?  my kernel version is 3.10.14 .       

              thanks a lot!

Hi
Is mkfs.exfat doing full format without being asked for it? It seems like it.
thanks, L
exfatprogs-1.1.2-2.fc35.x86_64
It takes 'mkfs.exfat ' ages.
many thanks, L.

I have an SD card that mounts/fsck fine on MacOS. However, fsck.exfat 1.1.0 reports
Unknown entry type 0xaa

I've noticed that -p option is not documented in fsck.exfat.8 man page
and I've tried to write a fix for it, but in order to do so I wanted to
understand the differences with -y.

To my undestanding -y always "fixes" what it can and -p depends on
a ERF_PREEN_YES flag that I don't understand where it comes from...

Could you please clarify so I can complete the man page?

@namjaejeon: Can you move this original code into exfat-tools organization?

Steps to do:

• Create a temporary org, for example exfat-tools-temp
• Transfer exfat-tools/exfat-tools into exfat-tools-temp
• Transfer your namjaejeon/exfat-tools into exfat-tools
• Transfer exfat-tools-temp/exfat-tools in your personal account
• Remove the exfat-tools-temp temporary org
• Merge the code in the main repository and all branches
• Add tags/releases in the new repo (based on the fork)
• Create a new temporary repo: namjaejeon/exfat-tools-issues
• Transfer all opened/closed issues from namjaejeon/exfat-tools into namjaejeon/exfat-tools-issues
• Transfer namjaejeon/exfat-tools-issues into exfat-tools org
• Transfer all opened/closed issues from exfat-tools/exfat-tools-issues into exfat-tools/exfat-tools
• Delete exfat-tools/exfat-tools-issues
• Archive or delete namjaejeon/exfat-tools

It will be perfect now, no lost.

Linked to:

• #45
• namjaejeon#42
• namjaejeon#18

I did a gpg --verify on the exfatprogs-1.1.3.tar.xz.asc file and it said it was a good signature but it also said that the key had expired.

Hello,
I have tested fsck.exfat 1.0.3 at master branch source code, with huge sdcard (512GB) after testing fsstress about 3 days.
The fsstress generated about 80000 directory entries.

While checking, it takes about 200secs that is somewhat too long.
Profiling with blktrace, about 10GB has been read by 80961 read requests each for 128KiB which is the cluster size.

I wonder if it's possible to reduce read granularity to smaller than cluster size, e.g. 4KiB,
because not every directory file is filled with child entries.
I think fsck's speed can be improved if we can read directory entries with small size in incremental manner. (4KB -> next 4KB, not cluster size)
I have tried patching it, but it's difficult because reads of fsck is too much cluster base.

I attach blktrace for 128KiB (200sec/10GiB) vs 4KiB (44sec/320MiB) read iter setup.
About 4KiB read, I have locally patched by just changing read_size of iter to 4KiB in exfat_de_iter_init(),
and escape from read_children() when I met End-Of-Directory marker not to read for unused entries.
(Maybe, 4KiB read change worked for test only because my filesystem does not have too many siblings.)
Yes, additionally, in read_children(),
I wonder if we don't need to escape from while loop, when we met End-Of-Directory marker?

I hope it can be changed.
Thanks.

blkparse_128k.tar.gz
blkparse_read_4k.tar.gz

mkfs.exfat.8 currently has a recommendation table from the SD association for these two options, but does not actually describe what this program does by default via

Specifically, the default boundary alignment is fixed at 1 MiB, and the default cluster size is set in

While using The Sleuth Kit (TSK) to analyze flash drives formatted without a label using mkfs.exfat, I encountered this error:

exfatfs_is_vol_label_dentry: incorrect volume label length

Which was caused by the label length check at L128 of exfatfs_meta.c because the default value (0x83) of the EntryType in mkfs.c indicates that the Volume Label Entry is in use even if there is really no label provided when formatting:

However, my understanding is that if the formatted volume does not have a label, the InUse bit of the EntryType should be set to 0 (i.e., EntryType should be 0x03) instead of 1 (0x83) according to Microsoft's exFAT specification¹². Windows Disk Management does set this bit accordingly, so the TSK commands work fine with those formatted by Windows. Although TSK could improve their check for wider compatibility, I think it makes sense to also modify L345 in mkfs.c to something like:

ed[0].type = ui->volume_label_len > 0 ? EXFAT_VOLUME : 0x03;

Please let me know if this sounds a reasonable suggestion or if there is something obvious I missed. Thank you!

When creating a new filesystem with mkfs.exfat, the BIOS Parameter Block sector size field (sect_size_bits) is filled based on the target block device's block size. This is normally fine except I'm generating an exfat image into a file for use on a device with a different sector size than my filesystem.

As a result, the exfat image has a fixed 9 (512 bytes), making it unsuitable for flashing onto a flash where the sector size is larger. A solution used by other mkfs utilities is to allow the user to override the BPB sector size field.

I'm curious if any thought has been given to resizing exfat file systems?

A similar effort was started in relan/exfat#145

Description

Fixed virtual-memory pagefile.sys file shows up as 0 bytes. I am sure it is 16 GiB
The ExFAT partition it is on is 16.1 GiB. intentionally created only for the pagefile.
But, the df command correctly shows that disk is 100% full

Host environment

fedora-37
kernel-6.0.12

Situation

• A Win10/Linux dual boot system is on an SSD (/dev/sda). Win10 has been restarted and now booted to Linux. Win10 works fine, and has been working fine since forever. Win10 on C: (sda4) has been configured to use fixed-size virtual-Memory paging-file in advanced system settings->performance->advanced->virtual memory . The pagefile for G:\ has been set to have both custom size, max size to be 16 GiB (= 16384 MiB), while pagefile for all other drives, including the system drive C:\, is set to None. This ensures pagefile.sys is created only on G:\, the ExFAT partition.
• The 16.1 GiB partition is formatted to have a ExFAT volume. The partition size chosen to account for filesystem metadata, the a 16 GiB file within (pagefile.sys) and perhaps a few other Win-OS made files/folders. I chose ExFAT over NTFS because, my guess is that ExFAT metadata would be much smaller and allow for a contiguously allocated 16 GiB file due to absence of scattered NTFS-MFT metadata clusters. The size 16.1 GiB was determined to be small enough to hold the file with room to spare.
• The pagefile.sys file was created by Win10, long ago. The partition was created and formatted to have an empty ExFAT volume. The subsequent re-configuration of Virtual Memory is followed by a reboot. Win10, during the next bootup, created the pagefile.sys on the empty ExFAT partition. Hence, the cluster allocation is expected to be contiguous, which is desirable for performance reasons.

When booting from Linux and mounting the ExFAT partition, the pagefile.sys shows up as 0 bytes.
I suspect that, because it is a system file (attrib +r +h +s in cmd speak), the ExFAT driver is misreporting.

Motivation: to see what the pagefile.sys file looks like under Linux. I am thinking/investigating whether the same pagefile.sys can be used as a Linux swap file when booted in as Linux, that way I can avoid creating another swap partition for Linux. I am aware of the possibility, that windows might hold on to loaded pagedata like cache in order to save time on warm reboots.

[root@sirius ~]# uname -a
Linux sirius 6.0.12-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Dec 8 16:58:47 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

[root@sirius ~]# rpm -qa | grep exfatprogs
exfatprogs-1.2.0-1.fc37.x86_64

[root@sirius ~]# sgdisk /dev/sda -i 6
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: 56C8147E-C776-40BA-9733-84C81FC3F566
First sector: 124100608 (at 59.2 GiB)
Last sector: 157786111 (at 75.2 GiB)
Partition size: 33685504 sectors (16.1 GiB)
Attribute flags: 0000000000000000
Partition name: 'WINPAGE'

[root@sirius ~]# mount -t exfat /dev/sda6 /mnt/a6

[root@sirius ~]# tail -2 /etc/mtab
portal /run/user/1000/doc fuse.portal rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
/dev/sda6 /mnt/a6 exfat rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro 0 0

[root@sirius ~]# df | grep sda6
/dev/sda6        16838656   16777632     61024 100% /mnt/a6

[root@sirius ~]# ls -l /mnt/a6
total 96
drwxr-xr-x. 2 root root 32768 Jul 28  2021 '$RECYCLE.BIN'
-rwxr-xr-x. 1 root root  8192 Dec 15 20:49  DumpStack.log.tmp
-rwxr-xr-x. 1 root root     0 Dec 15 20:50  pagefile.sys
drwxr-xr-x. 3 root root 32768 Jul 28  2021 'System Volume Information'
[root@sirius ~]# ls -la /mnt/a6
total 128
drwxr-xr-x. 4 root root 32768 Dec 17 10:36  .
drwxr-xr-x. 1 root root   676 Aug  9 18:57  ..
drwxr-xr-x. 2 root root 32768 Jul 28  2021 '$RECYCLE.BIN'
-rwxr-xr-x. 1 root root  8192 Dec 15 20:49  DumpStack.log.tmp
-rwxr-xr-x. 1 root root     0 Dec 15 20:50  pagefile.sys
drwxr-xr-x. 3 root root 32768 Jul 28  2021 'System Volume Information'

[root@sirius ~]# stat /mnt/a6/pagefile.sys
  File: /mnt/a6/pagefile.sys
  Size: 0               Blocks: 0          IO Block: 32768  regular empty file
Device: 8,6     Inode: 2326        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:dosfs_t:s0
Access: 2022-12-15 20:50:42.000000000 +0530
Modify: 2022-12-15 20:50:42.000000000 +0530
Change: 2022-12-15 20:50:42.000000000 +0530
 Birth: 2021-07-28 02:58:06.020000000 +0530

[root@sirius ~]# find /mnt/a6 -ls
        1     32 drwxr-xr-x   4 root     root        32768 Dec 17 10:36 /mnt/a6
     2324     32 drwxr-xr-x   3 root     root        32768 Jul 28  2021 /mnt/a6/System\ Volume\ Information
     2331     32 -rwxr-xr-x   1 root     root           76 Jul 28  2021 /mnt/a6/System\ Volume\ Information/IndexerVolumeGuid
     2332     32 -rwxr-xr-x   1 root     root           12 Jul 28  2021 /mnt/a6/System\ Volume\ Information/WPSettings.dat
     2333     32 drwxr-xr-x   3 root     root        32768 Aug  8  2021 /mnt/a6/System\ Volume\ Information/EDP
     2335     32 drwxr-xr-x   2 root     root        32768 Aug  8  2021 /mnt/a6/System\ Volume\ Information/EDP/Recovery
     2325     32 drwxr-xr-x   2 root     root        32768 Jul 28  2021 /mnt/a6/$RECYCLE.BIN
     2337     32 -rwxr-xr-x   1 root     root          129 Jul 28  2021 /mnt/a6/$RECYCLE.BIN/desktop.ini
     2326      0 -rwxr-xr-x   1 root     root            0 Dec 15 20:50 /mnt/a6/pagefile.sys
     2327     32 -rwxr-xr-x   1 root     root         8192 Dec 15 20:49 /mnt/a6/DumpStack.log.tmp

[root@sirius Downloads]# attr -l /mnt/a6/pagefile.sys 
Attribute "selinux" has a 29 byte value for /mnt/a6/pagefile.sys

[root@sirius ~]# getfattr -R --no-dereference -d -e hex -m '-' /mnt/a6/
getfattr: Removing leading '/' from absolute path names
# file: mnt/a6/
security.selinux=0x73797374656d5f753a6f626a6563745f723a646f7366735f743a733000

# file: mnt/a6//System Volume Information
security.selinux=0x73797374656d5f753a6f626a6563745f723a646f7366735f743a733000

# file: mnt/a6//System Volume Information/IndexerVolumeGuid
security.selinux=0x73797374656d5f753a6f626a6563745f723a646f7366735f743a733000

# file: mnt/a6//System Volume Information/WPSettings.dat
security.selinux=0x73797374656d5f753a6f626a6563745f723a646f7366735f743a733000

# file: mnt/a6//System Volume Information/EDP
security.selinux=0x73797374656d5f753a6f626a6563745f723a646f7366735f743a733000

# file: mnt/a6//System Volume Information/EDP/Recovery
security.selinux=0x73797374656d5f753a6f626a6563745f723a646f7366735f743a733000

# file: mnt/a6//$RECYCLE.BIN
security.selinux=0x73797374656d5f753a6f626a6563745f723a646f7366735f743a733000

# file: mnt/a6//$RECYCLE.BIN/desktop.ini
security.selinux=0x73797374656d5f753a6f626a6563745f723a646f7366735f743a733000

# file: mnt/a6//pagefile.sys
security.selinux=0x73797374656d5f753a6f626a6563745f723a646f7366735f743a733000

# file: mnt/a6//DumpStack.log.tmp
security.selinux=0x73797374656d5f753a6f626a6563745f723a646f7366735f743a733000


[root@sirius ~]# cd /mnt/a6
[root@sirius a6]# getfattr -R -d -m ".*"  .
# file: .
security.selinux="system_u:object_r:dosfs_t:s0"

# file: System Volume Information
security.selinux="system_u:object_r:dosfs_t:s0"

# file: System Volume Information/IndexerVolumeGuid
security.selinux="system_u:object_r:dosfs_t:s0"

# file: System Volume Information/WPSettings.dat
security.selinux="system_u:object_r:dosfs_t:s0"

# file: System Volume Information/EDP
security.selinux="system_u:object_r:dosfs_t:s0"

# file: System Volume Information/EDP/Recovery
security.selinux="system_u:object_r:dosfs_t:s0"

# file: $RECYCLE.BIN
security.selinux="system_u:object_r:dosfs_t:s0"

# file: $RECYCLE.BIN/desktop.ini
security.selinux="system_u:object_r:dosfs_t:s0"

# file: pagefile.sys
security.selinux="system_u:object_r:dosfs_t:s0"

# file: DumpStack.log.tmp
security.selinux="system_u:object_r:dosfs_t:s0"


[root@sirius ~]# umount /mnt/a6
[root@sirius ~]# /usr/sbin/dump.exfat /dev/sda6
exfatprogs version : 1.2.0
-------------- Dump Boot sector region --------------
Volume Length(sectors):                 33685504
FAT Offset(sector offset):              2048
FAT Length(sectors):                    4160
Cluster Heap Offset (sector offset):    8192
Cluster Count:                          526208
Root Cluster (cluster offset):          6
Volume Serial:                          0x7f97f433
Sector Size Bits:                       9
Sector per Cluster bits:                6

----------------- Dump Root entries -----------------
Volume entry type:                      0x83
Volume label:                           WINPAGE
Volume label character count:           7
Bitmap entry type:                      0x81
Bitmap start cluster:                   2
Bitmap size:                            65776
Upcase table entry type:                0x82
Upcase table start cluster:             5
Upcase table size:                      5836

---------------- Show the statistics ----------------
Cluster size:                           32768
Total Clusters:                         526208
Free Clusters:                          1907

This is one of those cases if dump.exfat provided more per-FAT-entry information, it would be helpful #173

Some command outputs from win10

PS C:\> cmd /c "dir G: /s /a"
 Volume in drive G is WINPAGE
 Volume Serial Number is 7F97-F433

 Directory of G:\

07/28/2021  02:49 AM    <DIR>          System Volume Information
07/28/2021  02:49 AM    <DIR>          $RECYCLE.BIN
01/05/2023  02:15 PM    17,179,869,184 pagefile.sys
01/05/2023  02:14 PM             8,192 DumpStack.log.tmp
               2 File(s) 17,179,877,376 bytes

 Directory of G:\System Volume Information

07/28/2021  02:49 AM    <DIR>          .
07/28/2021  02:49 AM    <DIR>          ..
07/28/2021  02:49 AM                76 IndexerVolumeGuid
07/28/2021  02:54 AM                12 WPSettings.dat
08/08/2021  05:07 PM    <DIR>          EDP
               2 File(s)             88 bytes

 Directory of G:\System Volume Information\EDP

08/08/2021  05:07 PM    <DIR>          .
08/08/2021  05:07 PM    <DIR>          ..
08/08/2021  05:07 PM    <DIR>          Recovery
               0 File(s)              0 bytes

 Directory of G:\System Volume Information\EDP\Recovery

08/08/2021  05:07 PM    <DIR>          .
08/08/2021  05:07 PM    <DIR>          ..
               0 File(s)              0 bytes

 Directory of G:\$RECYCLE.BIN

07/28/2021  02:49 AM    <DIR>          .
07/28/2021  02:49 AM    <DIR>          ..
07/28/2021  02:49 AM               129 desktop.ini
               1 File(s)            129 bytes

     Total Files Listed:
               5 File(s) 17,179,877,593 bytes
              12 Dir(s)      62,488,576 bytes free

PS C:\WINDOWS\system32> pwsh -Command { cd G:\ ; attrib /S /D }
                     G:\System Volume Information\EDP\Recovery
A                    G:\System Volume Information\IndexerVolumeGuid
A                    G:\System Volume Information\WPSettings.dat
                     G:\System Volume Information\EDP
A  SH                G:\$RECYCLE.BIN\desktop.ini
   SH                G:\System Volume Information
   SH                G:\$RECYCLE.BIN
A  SH                G:\pagefile.sys
A  SH                G:\DumpStack.log.tmp

PS C:\WINDOWS\system32> Get-Volume -DriveLetter G  | Format-List


ObjectId             : {1}\\CAPELLA-PC\root/Microsoft/Windows/Storage/Providers_v2\WSP_Volume.ObjectId="{1b5bc408-e673-
                       11e9-95e1-806e6f6e6963}:VO:\\?\Volume{56c8147e-c776-40ba-9733-84c81fc3f566}\"
PassThroughClass     :
PassThroughIds       :
PassThroughNamespace :
PassThroughServer    :
UniqueId             : \\?\Volume{56c8147e-c776-40ba-9733-84c81fc3f566}\
AllocationUnitSize   : 32768
DedupMode            : NotAvailable
DriveLetter          : G
DriveType            : Fixed
FileSystem           : exFAT
FileSystemLabel      : WINPAGE
FileSystemType       : Unknown
HealthStatus         : Warning
OperationalStatus    : Full Repair Needed
Path                 : \\?\Volume{56c8147e-c776-40ba-9733-84c81fc3f566}\
Size                 : 17242783744
SizeRemaining        : 62488576
PSComputerName       :

NTFS3 is fine. I also have a win11 installed to a different HDD

[root@sirius ~]# mount -t ntfs3 /dev/sdc9 /mnt/c9
[root@sirius ~]# df -k | grep sdc9
/dev/sdc9        96567292   37994684  58572608  40% /mnt/c9
[root@sirius ~]# ls -la /mnt/c9 | grep sys
-rwxr-xr-x. 1 root root 6843432960 Sep 24 19:38 hiberfil.sys
-rwxr-xr-x. 1 root root 2550136832 Sep 24 19:38 pagefile.sys
-rwxr-xr-x. 1 root root  268435456 Sep 24 19:38 swapfile.sys

[root@sirius ~]# df -k | grep -E "sdc9"
/dev/sdc9        96567292   37994684  58572608  40% /mnt/c9

[root@sirius Downloads]# stat /mnt/c9/pagefile.sys 
  File: /mnt/c9/pagefile.sys
  Size: 2550136832	Blocks: 4980736    IO Block: 4096   regular file
Device: 8,41	Inode: 14073       Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:dosfs_t:s0
Access: 2022-09-24 19:38:15.189021700 +0530
Modify: 2022-09-24 19:38:15.189021700 +0530
Change: 2022-09-24 19:38:15.189021700 +0530
 Birth: 2021-12-04 04:24:41.228947400 +0530

[root@sirius ~]# attr -l /mnt/c9/pagefile.sys 
[root@sirius ~]# getfattr -R -d -m ".*"  /mnt/c9/pagefile.sys 
[root@sirius ~]# 

[root@sirius ~]# cat /etc/mtab | grep sdc9
/dev/sdc9 /mnt/c9 ntfs3 rw,relatime,uid=0,gid=0,iocharset=utf8 0 0

Ref

• similar bug in fuse-exfat relan/exfat#46

Description

Can't find documentation for both
A) ExFAT mount option documentation
B) ExFAT driver developer guide documentation linux.git/tree/Documentation/filesystems

The file super.c https://github.com/namjaejeon/linux-exfat-oot/blob/3eef540417547ae7eea6d8bcae97b797e8fb2cbb/super.c#L345 , function exfat_parse_param() lists the options parsed.
Seems like the options include :

• parsed-ops: uid, gid, umask, dmask, fmask, allow_utime, charset, errors, discard, keep_last_dots, sys_tz, time_offset,
• no-ops: utf8, debug, namecase, codepage

I was looking for mount options to do something like change the default uid just for confirmation, as well as explanations for options, which options are implmented and which are not, and maybe other options that I do not know of.

[root@sirius ~]# cat /etc/mtab | grep -i exfat
/dev/sda16 /mnt/a16 exfat rw,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro 0 0
/dev/sda6 /mnt/a6 exfat rw,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro 0 0

As ExFAT is mostly a upper-limits expanded version of VFAT/FAT32, I may assume that the options general to all filesystems, and options specific to FAT filesystems, described in the corresponding sections of man -s 8 mount, also hold true for ExFAT.

man mount
- § FILESYSTEM-INDEPENDENT MOUNT OPTIONS
  states: points out when FAT systems deviate 
- § FILESYSTEM-SPECIFIC MOUNT OPTIONS
  - § § Mount options for fat
    excerpt: (Note: fat is not a separate filesystem, but a common part of the msdos, umsdos and vfat filesystems.)

However, if it is the case, that there are no ExFAT specific options, then this needs to be explicitly mentioned somewhere.

Expected Outcome

• man exfat or man mount.exfat should work, files /usr/share/man/man5/exfat.5.gz or /usr/share/man/man8/mount.exfat.8.gz should exist.
• To a lesser extent it may be nice for ExFAT kernel developer code architecture documentation also existed at linux.git/tree/Documentation/filesystems

logs

[root@sirius ~]# find /usr/share/man/ | grep -i exfat
/usr/share/man/man8/dump.exfat.8.gz
/usr/share/man/man8/exfat2img.8.gz
/usr/share/man/man8/exfatlabel.8.gz
/usr/share/man/man8/fsck.exfat.8.gz
/usr/share/man/man8/mkfs.exfat.8.gz
/usr/share/man/man8/tune.exfat.8.gz
/usr/share/man/man8/partclone.exfat.8.gz

The documentation man -s 5 ext4 from package e2fsprogs details mount options.

[root@sirius ~]# find /usr/share/man/ | grep -i ext4
/usr/share/man/man5/ext4.5.gz
/usr/share/man/man8/fsck.ext4.8.gz
/usr/share/man/man8/mkfs.ext4.8.gz
/usr/share/man/man8/partclone.ext4.8.gz
/usr/share/man/man8/partclone.ext4dev.8.gz
[root@sirius ~]# rpm -qf /usr/share/man/man5/ext4.5.gz
e2fsprogs-1.46.5-3.fc37.x86_64

The documentation man -s 8 mount from package util-linux-core details the mount options of both general and FAT specific.

[root@sirius ~]# rpm -qf /usr/share/man/man8/mount.8.gz
util-linux-core-2.38.1-1.fc37.x86_64

Misc

• The other available documentation on the web seems to be from exfat-fuse package
  https://manpages.debian.org/jessie/exfat-fuse/mount.exfat.8.en.html
• history-computer.com/exfat-vs-fat32

This error is being hit by one of the buildroot autobuilders here:

In file included from mkfs.c:21:
mkfs.c: In function 'exfat_setup_boot_sector':
mkfs.c:60:14: error: format '%llu' expects argument of type 'long long unsigned int', but argument 2 has type 'long unsigned int' [-Werror=format=]
  exfat_debug("Volume Length(sectors) : %llu\n",
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../include/libexfat.h:94:12: note: in definition of macro 'exfat_msg'
     printf(fmt, ##__VA_ARGS__);  \
            ^~~
mkfs.c:60:2: note: in expansion of macro 'exfat_debug'
  exfat_debug("Volume Length(sectors) : %llu\n",
  ^~~~~~~~~~~
../include/libexfat.h:96:12: error: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Werror=format=]
     printf("[%s:%4d] " fmt,    \
            ^~~~~~~~~~~
../include/libexfat.h:103:31: note: in expansion of macro 'exfat_msg'
 #define exfat_debug(fmt, ...) exfat_msg(EXFAT_DEBUG, fmt, ##__VA_ARGS__)
                               ^~~~~~~~~
mkfs.c:60:2: note: in expansion of macro 'exfat_debug'
  exfat_debug("Volume Length(sectors) : %llu\n",
  ^~~~~~~~~~~
mkfs.c:60:43: note: format string is defined here
  exfat_debug("Volume Length(sectors) : %llu\n",
                                        ~~~^
                                        %lu
mkfs.c: At top level:
cc1: error: unrecognized command line option '-Wno-address-of-packed-member' [-Werror]
cc1: all warnings being treated as errors
make[3]: *** [Makefile:403: mkfs.o] Error 1

The source package when built provides libexfat.so but this is useless unless there is some public header/pkgconfig file to consume this library.

Can you detach this fork from old upstream?

At this time:

• This branch is 125 commits ahead, 5 commits behind namjaejeon:master

Contact GitHub: "Attach, detach, or reroute forks"

• https://github.com/contact
• https://support.github.com/contact?tags=rr-forks

Thanks in advance.

Both tune.exfat and exfatlabel don't print an error when setting an invalid volume serial.

exfatprogs version : 1.2.1

Create a container:

fallocate -l 1G ./mycontainer

Format it as exFAT:

mkfs.exfat ./mycontainer

Display volume serial:

tune.exfat -i ./mycontainer | grep serial

should give something like volume serial : 0x66fb7876

Attempt to set an invalid serial (serial numbers are supposed to be hex digits):

tune.exfat -I 0x123qq678 ./mycontainer

The command completes successfully. tune.exfat -i ./mycontainer | grep serial reports volume serial : 0x123 which shows that the serial was truncated. The command should instead report an error and not proceed with setting any serial number.

Additionally, if you try to set a too long serial number:

tune.exfat -I 0x1234567890abcd ./mycontainer

then tune.exfat -i ./mycontainer | grep serial will give volume serial : 0x7890abcd which is the last 8 digits of the serial that was attempted to be set. The command should instead report an error and not proceed with setting any serial number.

fsck.exfat --repair does not ask me anything interactively (always answering n instead) and fsck.exfat --repair-yes does the same.

❯ sudo fsck.exfat -r /dev/disk/by-uuid/[REDACTED]
exfatprogs version : 1.1.3
ERROR: [REDACTED]: first cluster is wrong. Truncate (y/N)? n
ERROR: [REDACTED]: first cluster is wrong. Truncate (y/N)? n
[...]

❯ sudo fsck.exfat -y /dev/disk/by-uuid/[REDACTED]
exfatprogs version : 1.1.3
ERROR: [REDACTED]: first cluster is wrong. Truncate (y/N)? n
ERROR: [REDACTED]: first cluster is wrong. Truncate (y/N)? n
[...]

This error is being hit by one of the buildroot autobuilders here:

In file included from repair.c:9:
../include/libexfat.h:73:1: error: unknown type name 'ssize_t'; did you mean 'size_t'?
 ssize_t exfat_read(int fd, void *buf, size_t size, off_t offset);
 ^~~~~~~
 size_t
../include/libexfat.h:73:52: error: unknown type name 'off_t'
 ssize_t exfat_read(int fd, void *buf, size_t size, off_t offset);
                                                    ^~~~~
../include/libexfat.h:74:1: error: unknown type name 'ssize_t'; did you mean 'size_t'?
 ssize_t exfat_write(int fd, void *buf, size_t size, off_t offset);
 ^~~~~~~
 size_t
../include/libexfat.h:74:53: error: unknown type name 'off_t'
 ssize_t exfat_write(int fd, void *buf, size_t size, off_t offset);
                                                     ^~~~~
../include/libexfat.h:76:1: error: unknown type name 'ssize_t'; did you mean 'size_t'?
 ssize_t exfat_utf16_enc(const char *in_str, __u16 *out_str, size_t out_size);
 ^~~~~~~
 size_t
../include/libexfat.h:77:1: error: unknown type name 'ssize_t'; did you mean 'size_t'?
 ssize_t exfat_utf16_dec(const __u16 *in_str, size_t in_len,
 ^~~~~~~
 size_t
In file included from repair.c:10:
fsck.h:25:2: error: unknown type name 'off_t'
  off_t   dentry_file_offset;
  ^~~~~
fsck.h:38:2: error: unknown type name 'off_t'
  off_t   de_file_offset; /* offset in dentries buffer */
  ^~~~~
fsck.h:39:2: error: unknown type name 'off_t'
  off_t   next_read_offset;
  ^~~~~
repair.c: In function 'fix_bs_checksum':
repair.c:32:6: error: implicit declaration of function 'exfat_write'; did you mean 'exfat_err'? [-Werror=implicit-function-declaration]
  if (exfat_write(exfat->blk_dev->dev_fd,
      ^~~~~~~~~~~
      exfat_err
repair.c: At top level:
cc1: error: unrecognized command line option '-Wno-address-of-packed-member' [-Werror]
cc1: all warnings being treated as errors