truncate on exfat doesn't seem to work

[dlundqvist]

Hi,

Using truncate on Linux with exfat does not seem to work. ZuluSCSI indicates with three blinks that it cannot find any image, and it doesn't even create/update zululog.txt. Anything I can do to troubleshoot this issue?

[aperezbios]

@dlundqvist there's insufficient information here to be able to suggest much of anything. Let's start with the basics. Does your board work properly with a non-exFAT SD card? Have you tried more than one SD card? What version of the firmware are you running? What model of ZuluSCSI are you using? Assume we know nothing about what you've tried up until now, because we don't :)

Most of these questions can be answered by providing us with the output from your ZuluSCSI, which you will need to collect via USB serial console, since it isn't writing a log to the SD card. All you need to do is have the board connected to a modern computer via USB, and have a terminal emulation app running, such as GNU screen. The virtual serial interface should enumerate as /dev/ttyACM*

[dlundqvist]

Apologies, I shouldn't have been so terse.

Does your board work properly with a non-exFAT SD card?

Yes, the board works fine with vfat and exfat. It's just that creating image file via truncate on exfat does not work. Creating a file via dd works perfectly fine.

Have you tried more than one SD card?

Yes.

What version of the firmware are you running?

v2025.01.09

What model of ZuluSCSI are you using?

ZuluSCSI RP2040

I'll hook USB and get more information.

[dlundqvist]

From USB serial:

[1448620ms] SD card removed, trying to reinit
[1492868ms] SD card reinit succeeded
[1492868ms] SD card detected, FAT64 volume size: 60902 MB
[1492869ms] SD MID: 0x03, OID: 0x53 0x44
[1492869ms] SD Name: SR64G
[1492869ms] SD Date: 3/2019
[1492870ms] SD Serial: 0x7411AA94
[1492870ms] Config file zuluscsi.ini not found, using defaults
[1492872ms] Active configuration:
[1492872ms] -- SelectionDelay = 255
[1492872ms] -- EnableUnitAttention = No
[1492873ms] -- EnableSCSI2 = Yes
[1492873ms] -- EnableSelLatch = No
[1492873ms] -- MapLunsToIDs = No
[1492874ms] -- EnableParity = Yes
[1492882ms] Finding images in directory /:
[1492882ms] -- Opening /HD1.img for id:1 lun:0
[1492883ms] ---- Error: image file /HD1.img is empty
[1492883ms] ---- Failed to load image
[1492884ms] -- Platform supports ROM drive up to 3740 kB
[1492884ms] ---- ROM drive image not detected
[1492885ms] SCSI ID: 1, BlockSize: 512, Type: 0, Quirks: 0, Size: 0kB
[1492885ms] No images found, enabling RAW fallback partition
[1492887ms] ---- Limiting RAW image mapping to SD card sector count: 124735488
[1492887ms] ---- Configuring as disk drive drive
[1492888ms] ---- Read prefetch enabled: 8192 bytes

This is after creating HD1.img with truncate -s 1077511680 /media/daniel/SCSI/HD1.img.

[aperezbios]

@dlundqvist it doesn't look like the image is being properly created, which has nothing to do with the ZuluSCSI firmware itself, since you used the truncate command, which is part of GNU coreutils. This is not a firmware bug. The firmware sees a zero-byte file, which it simply cannot use. I don't know why truncate doesn't work under Linux with exFAT, but it might be worth reporting to the GNU coreutils project

Error: image file /HD1.img is empty

[dlundqvist]

The file is there, and it's the correct size and if read with hexdump it's all zeroes:

neptune ~% truncate -s 1077511680 /media/daniel/SCSI/HD1.img
neptune ~% ls -lh /media/daniel/SCSI                        
total 1.1G
-rwxr-xr-x 1 daniel users 1.1G Jan 29 22:00 HD1.img
neptune ~% hexdump -C /media/daniel/SCSI/HD1.img
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
40398600

This is because it's sparse (which is what happens when using truncate and extending a file). Do ZuluSCSI handle sparse files on exfat correctly?

The reason why I created this issue is because ZuluSCSI documentation shows to use truncate on Linux. It took me a little while to realize it was this that caused trouble for me when starting to use my board.

[aperezbios]

@dlundqvist that makes sense. We use the sdfat library. A cursory examination of the official sdFat repo seems to indicate that it does not have any support for sparse files at this time, or at least the word "sparse" does not exist anywhere in the entire repository, nor any associated issues: https://github.com/search?q=repo%3Agreiman%2FSdFat%20sparse&type=code