Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Work out why linux FAT driver likes to read all sorts of (unused) data #3

Open
ryankurte opened this issue Apr 12, 2022 · 2 comments
Open
Labels
help wanted Extra attention is needed

Comments

@ryankurte
Copy link
Owner

ryankurte commented Apr 12, 2022

when running using rust fatfs (see tests) reads are as expected, however, when linked via usbd_scsi linux likes to walk a bunch of unused chunks for reasons yet unknown.

this doesn't seem to impact usability, but, it'd be nice to know what's up.

@ryankurte
Copy link
Owner Author

ryankurte commented Apr 12, 2022

fatcat shows the disk configuration is as expected:

➜  ~ fatcat -i fat16test.img 
FAT Filesystem information

Filesystem type: FAT16   
OEM name: UF2 UF2 
Total sectors: 7998
Total data clusters: 8192
Data size: 4194304 (4M)
Disk size: 4094976 (3.90527M)
Bytes per sector: 512
Sectors per cluster: 1
Bytes per cluster: 512
Reserved sectors: 1
Root entries: 64
Root clusters: 4
Sectors per FAT: 32
Fat size: 16384 (16K)
FAT1 start address: 0000000000000200
FAT2 start address: 0000000000004200
Data start address: 0000000000008200
Root directory cluster: 0
Disk label: BLUEPILL   

Free clusters: 7999/8192 (97.644%)
Free space: 4095488 (3.90576M)
Used space: 98816 (96.5K)

though when listing directories fatcat and linux seemingly disagree on available files, and fatcat cannot retrieve data for the first.

➜  ~ ls -al /media/ryan/BLUEPILL 
total 71
drwxr-xr-x  2 ryan ryan  2048 Jan  1  1970 .
drwxr-x---+ 7 root root  4096 Apr 13 09:36 ..
-r--r--r--  1 ryan ryan     7 Jan  1  1980 a.txt
-rw-r--r--  1 ryan ryan 65536 Jan  1  1980 b.bin

➜  ~ sudo fatcat fat16test.img -l /    
Listing path /
Directory cluster: 0
f 0/0/1980 00:00:00  BLUEPILL                       c=0 s=0 (0B)
f 0/0/1980 00:00:00  b.bin                          c=3 s=65536 (64K)

image copied from current device:
fat16test.img.zip

@ryankurte
Copy link
Owner Author

ryankurte commented Apr 12, 2022

directories seem to look a little weird, i would have expected to see a.txt in cluster 0 / the root directory, but, do not

➜  ghostfat git:(main) sudo fatcat /dev/sdd -l /
Listing path /
Directory cluster: 0
f 0/0/1980 00:00:00  GHOSTFAT                       c=0 s=0 (0B)
f 19/4/2022 09:10:14  b.bin                          c=3 s=56 (56B)
➜  ghostfat git:(main) sudo fatcat /dev/sdd -L 0
Listing cluster 0
Directory cluster: 0
f 0/0/1980 00:00:00  GHOSTFAT                       c=0 s=0 (0B)
f 19/4/2022 09:10:14  b.bin                          c=3 s=56 (56B)
➜  ghostfat git:(main) sudo fatcat /dev/sdd -L 1
Listing cluster 1
Directory cluster: 1
➜  ghostfat git:(main) sudo fatcat /dev/sdd -L 2
Listing cluster 2
Directory cluster: 2
f 0/0/1980 00:00:00  12345
                        c=0 s=0 (0B)

➜  ghostfat git:(main) sudo fatcat /dev/sdd -o
Computing FAT cache...
Building the chains...
Found 4 chains

Running the recursive differential analysis...
Exploring 0

Having a look at the chains...
Exploring 2
There is 1 orphaned elements:
* Directory clusters 2 to 2: 1 elements, 0B

Estimation of orphan files total sizes: 0 (0B)

@ryankurte ryankurte added bug Something isn't working help wanted Extra attention is needed and removed bug Something isn't working labels Apr 18, 2022
@ryankurte ryankurte changed the title Work out why linux FAT driver likes to read all sorts of (undefined) data Work out why linux FAT driver likes to read all sorts of (unused) data Apr 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant