ATRFS: Mount ATR files as local directories under Linux or Mac

[Piotr D. Kaczorowski]

1 minute ago, pcrow said:

I anticipate the most common use case is moving files around that originated on the Atari and will end up on an Atari.  I don't want to have files getting modified when copying them.

 

However, it would be fine to have a magic extension that does text conversion from ATASCII to ASCII.  Something like adding ".text" or ".ascii" to the file name when reading it.  As long as the magic extension is four or more characters, it wouldn't interfere with any Atari files.  I already do that for ".info" which shows the binary load blocks or a summary of the BASIC structure of applicable files.

You know, we live in times (e.g., ChatGPT) where determining whether a file is a text file or not is essentially trivial. In the future, there could be an option that such files are converted both ways. Other binary files might have (e.g., in Unix) an executable flag, which would indicate that they are binary and are not subject to conversion."

 

[pcrow]

5 hours ago, Piotr D. Kaczorowski said:

That's why I mentioned adding "--dummy" to the current version. It should be very simple for you, and it will make the transition from one library to the other quite easy.

I still don't get exactly what the "--dummy" behavior would do.  I know several commands have --pretend, but it's not like it does much before mounting.

[pcrow]

Another small update:  I made .sector# files writable, so you can modify individual sectors.  With some clever use of 'dd', you can edit individual bytes, though I would recommend copying the sector, editing it, and writing it back.  Writing past the end of the sector returns ENOSPC because simple EOF didn't stop dd from continuing to write.

[pcrow]

The --create option now works for all file systems, even ones without write support.  This can let you create images of non-standard sizes that will work but can't be made directly.  Mostly this was for my fun, as it was interesting to find subtle oddities in the file systems and find the limits for what they can support.  Notably:

• DOS 3: 1048 sectors lets you have 128K instead of 127K free
• DOS 4: 1482 sectors gives a little more space on a DS/DD image; also 1482 sectors on a 1050 enhanced density works
• DOS XE: 3960 DD sectors (or double that SD) works.  More requires modifying the drive table in the DOS executable, which also increases the RAM consumption.

I haven't implemented write support for any of those three, and I'm not sure if I will.

[+x=usr(1536)]

54 minutes ago, pcrow said:

I haven't implemented write support for any of those three, and I'm not sure if I will.

Just being able to mount the images and extract the files is likely to be 99.9% of what the FS support is used for.  There may be some corner cases in favour of write support, but given that those three versions of DOS never saw wide adoption it's probably safe to back-burner that as a feature until a suitably-pressing need arises.

[pcrow]

Someone asked to be able to mount a whole directory of ATR files all at once, so I've added mountdir.sh.

 

mountdir.sh source target

 

The target should be an empty directory (or it will be created).  It will copy the directory tree from source--just the directories.  For any regular file that isn't an ATR file, it will create a symlink to the original.  For any file that is an ATR file, it will create a directory of the same name and mount it with atrfs.

 

It's a fairly simple Bash script, so it should be easy to modify if you have slightly different needs.  There may be some Linux-specific bits, like looking for /etc/fuse.conf and assuming a specific format for the output of the 'mount' command to find mounts when cleaning up.

[Ray Gillman]

My interests are less ambitious.  I just want a 16 meg Mydos ATR file - got plenty of Sparta atr's (or mypicodos whatever that is) of that size but all of the MyDos files are 181K

[pcrow]

5 hours ago, Ray Gillman said:

My interests are less ambitious.  I just want a 16 meg Mydos ATR file - got plenty of Sparta atr's (or mypicodos whatever that is) of that size but all of the MyDos files are 181K

Well, atrfs does have a '--create' option.  So if you can build it, you can do:

atrfs --create --fs=mydos --sectors=65535 --secsize=256 --name=mydos_big.atr

 

[Ray Gillman]

On 9/24/2023 at 2:32 PM, pcrow said:

Well, atrfs does have a '--create' option.  So if you can build it, you can do:

atrfs --create --fs=mydos --sectors=65535 --secsize=256 --name=mydos_big.atr

 

I will try that too but for now I found one somewhere which appears to be a 16MB Mydos disk 

My Dos 4.53 16MB.atr

[beqelessen]

On 9/20/2023 at 12:46 AM, pcrow said:

Someone asked to be able to mount a whole directory of ATR files all at once, so I've added mountdir.sh.

 

mountdir.sh source target

 

The target should be an empty directory (or it will be created).  It will copy the directory tree from source--just the directories.  For any regular file that isn't an ATR file, it will create a symlink to the original.  For any file that is an ATR file, it will create a directory of the same name and mount it with atrfs.

 

It's a fairly simple Bash script, so it should be easy to modify if you have slightly different needs.  There may be some Linux-specific bits, like looking for /etc/fuse.conf and assuming a specific format for the output of the 'mount' command to find mounts when cleaning up.

@pcrow thank you for taking the time to do that!

 

I think @woj was asking about a FUSE driver for APT partitions, not ATR files:

 

That's a completely different project!

 

Where can I find more information about APT? I don't know what it stands for and the name clashes with the Android packaging format.

[pcrow]

I wasn't familiar with APT for hard disk partitioning.  The linked document is for users on the Atari side, so I'm not clear on the technical side, but it appears that it's using the regular MBR partition table scheme that Linux should recognize automatically, but some of those partitions are subdivided on the Atari side into separate ATR partitions.  So what's needed is support for parsing that internal partition table into separate sub-partitions.

 

One option would be to add support for these sub-partitions as a Linux module so that they show up as separate devices.

 

A simpler option would be to have a program break these out in user space.

 

I suppose it would be possible for ATRFS to read the raw partition block device (e.g., /dev/sdb3), use a command line parameter to specify an ATR sub-partition, parse the table, and then memmap the range for the partition just like an ATR file.  Obviously it would also need some options to display the table and such.

 

So, yes, this all hinges on getting details on the format.

 

I suppose, when I have time, I could just create some examples and figure it out from what is written to the disk, but someone should have the specs.

[woj]

You say "linked document", but I am not sure what you are referring to, but I found this if it is of any help: http://drac030.krap.pl/APT_spec.pdf

[pcrow]

5 minutes ago, woj said:

You say "linked document", but I am not sure what you are referring to, but I found this if it is of any help: http://drac030.krap.pl/APT_spec.pdf

I could swear there was a link to a user manual for APT above, but I don't see it now.  (I had clicked on it and browsed through it, so I know I'm not imagining it.)  Anyway, the spec you posted is exactly what I need.

[beqelessen]

2 hours ago, woj said:

You say "linked document", but I am not sure what you are referring to, but I found this if it is of any help: http://drac030.krap.pl/APT_spec.pdf

Superb, thanks @woj. Armed with that, I was able to use millionshort to find excellent related resources:

 

https://millionshort.com/search?keywords=http%3A%2F%2Fdrac030.krap.pl%2FAPT_spec.pdf&remove=1000

 

APT is "Atari Partition Table". (Of course it is.)

 

 

[woj]

So, after all this time I finally tried it! Compiled clean and in principle works, but one problem identified and one feature request:

 

1. Problem identified: I tried to copy a large file to an ED disk earlier created with dir2atr, cp said the file would not fit, not enough free space. The file is large to almost fill the disk, but not that large. (I still have to check if that empty ATR was really empty).

 

2. Feature request: it would be super cool for .bootsectors to be writable to have a way to boot initialize the disk anyway I want (reason why I used dir2atr in the first place to initialize the disk). 

[pcrow]

On 12/25/2023 at 10:00 AM, woj said:

So, after all this time I finally tried it! Compiled clean and in principle works, but one problem identified and one feature request:

 

1. Problem identified: I tried to copy a large file to an ED disk earlier created with dir2atr, cp said the file would not fit, not enough free space. The file is large to almost fill the disk, but not that large. (I still have to check if that empty ATR was really empty).

 

2. Feature request: it would be super cool for .bootsectors to be writable to have a way to boot initialize the disk anyway I want (reason why I used dir2atr in the first place to initialize the disk). 

I'll look into the disk full issue.  It would help if you sent me a copy of the image and the file that should have fit.  Is this DOS 2.5 format?  Remember that DOS 2.5 only uses sectors 1-1023 for data, skipping 1-3, 360-368, and 720, for 1010 data sectors.  Each sector has 3 bytes of overhead, and the last sector can't be full or it pushes to the next sector using zero bytes of data.  So the maximum file size is 126249 bytes on a freshly formatted disk.  MyDOS and SpartaDOS use the disk differently, so the number are different (and a bit larger in both cases).

 

Making .bootsectors writable sounds reasonable, though it's a little tricky if the number of boot sectors changes.  Generally it shouldn't be more than 3 for DD images, but for SD images, it could go up to 256.  The weird part is that the size changes based on the contents of the first sector, not on how much data you write.

 

I hope to get to this soon.

[pcrow]

On 12/25/2023 at 10:00 AM, woj said:

2. Feature request: it would be super cool for .bootsectors to be writable to have a way to boot initialize the disk anyway I want (reason why I used dir2atr in the first place to initialize the disk). 

Done!  I just pushed the change.

 

The number of boot sectors is the second byte of sector 1.  If you overwrite that value, you change the size of .bootsectors to match.  Your write is limited by the new size.  I also figured it didn't make sense to have more than 3 boot sectors unless it's single density, as the OS boot routines can't handle double density.

[pcrow]

Also, you can always write to any individual sector, so you could separately write .sector1, .sector2, and .sector3.  Sector numbers are in decimal unless prefixed with '0x' or '$' (which is awkward for a filename, obviously).

[woj]

4 hours ago, pcrow said:

Done!  I just pushed the change.

 

The number of boot sectors is the second byte of sector 1.  If you overwrite that value, you change the size of .bootsectors to match.  Your write is limited by the new size.  I also figured it didn't make sense to have more than 3 boot sectors unless it's single density, as the OS boot routines can't handle double density.

Super! I still can't check it out for a couple of days due to holidays, but I will. Also will diagnose the file size issue a bit more (I am certain though the file was smaller than what you quoted. What I do not remember is if I was not using Midnight Commander to copy the file, which may or may not have affected atrfs operation).

[pcrow]

7 hours ago, woj said:

Also will diagnose the file size issue a bit more

If it does appear to be an ATRFS issue, please send me the ATR file and the file you're trying to copy into it.  That will make it easy to debug.

[woj]

On 1/1/2024 at 4:48 AM, pcrow said:

Done!  I just pushed the change.

Strange, git pull says "Already up-to-date." and I do not see any recent commits on GitHub either. Just to make sure, this is the repo I cloned: https://github.com/pcrow/atari_8bit_utils

[woj]

So, attached is the file that is (way) below the 126249 threshold (it's filled with 'A', the contents is irrelevant). Then I did this:

 

woj@impreza:~/temp/atrfs $ mkdir disk; atrfs --create --name=tst.atr --sectors=1040 --fs=dos25 disk
woj@impreza:~/temp/atrfs $ cp tst.bin disk/
woj@impreza:~/temp/atrfs $ ls -la disk/
total 502
drwxr-xr-x 2 woj woj   1024 Jan  2 15:08 .
drwxrwxr-x 3 woj woj   4096 Jan  2 15:08 ..
-r--r--r-- 1 woj woj    305 Jan  2 15:08 .bootinfo
-r--r--r-- 1 woj woj    384 Jan  2 15:08 .bootsectors
-r--r--r-- 1 woj woj    302 Jan  2 15:08 .fsinfo
-rw-r--r-- 1 woj woj 116460 Jan  2 15:08 tst.bin
woj@impreza:~/temp/atrfs $ ls -la
total 260
drwxrwxr-x  3 woj woj   4096 Jan  2 15:08 .
drwxr-xr-x 31 woj woj   4096 Jan  2 15:04 ..
drwxr-xr-x  2 woj woj   1024 Jan  2 15:08 disk
-rw-r--r--  1 woj woj 133136 Jan  2 15:08 tst.atr
-rw-rw-r--  1 woj woj 124335 Jan  2 15:03 tst.bin

 

In this case the file is truncated silently, if I, however, create an image with dir2atr (also empty) and mount it, I get an explicit message saying there is no space left to copy the file (and it is copied partially).

tst.bin

[pcrow]

5 hours ago, woj said:

Strange, git pull says "Already up-to-date." and I do not see any recent commits on GitHub either. Just to make sure, this is the repo I cloned: https://github.com/pcrow/atari_8bit_utils

Well, I committed the fix, but I forgot to push it.  Try now.  Sorry.

[woj]

2 hours ago, pcrow said:

Well, I committed the fix, but I forgot to push it.  Try now.  Sorry.

Works, but it was not entirely problem free, and I also noticed one more thing not related to boot sectors. 

 

1. Copying the boot sectors code works only if cp is used with --no-preserve=all or an equivalent when using a file manager (Midnight Commander in my case). Otherwise, there are no error messages returned, but the copy is effect-less.

 

2. I noticed the file names are not automatically upper-cased when copying onto the image. Might be a good idea to at least offer such conversion as an option to ATRFS. (In all honesty, I have no clue if Atari file systems are case sensitive, or some of them, but it was a bit surprising that e.g. DOS.SYS was not found by MyDOS because I have it in lowercase on my native file system).

[pcrow]

1 hour ago, woj said:

2. I noticed the file names are not automatically upper-cased when copying onto the image. Might be a good idea to at least offer such conversion as an option to ATRFS. (In all honesty, I have no clue if Atari file systems are case sensitive, or some of them, but it was a bit surprising that e.g. DOS.SYS was not found by MyDOS because I have it in lowercase on my native file system).

I believe most if not all file systems on Atari are case-sensitive, and do not block lower-case filenames.  I haven't tested widely, but I know I used mixed case with MyDOS.  I can see it being a valid feature request for an option to mount case-insensitive and create all new files in upper case.  I'll think about how I might do that in a general way instead of impacting the code for each file system.