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

[+x=usr(1536)]

Memos to self for future testing:

• Gigantic images (e.g., 1MB+)
• Mount an atrfs filesystem via FujiNet
• Show atrfs mounts in Finder sidebar (may be macFUSE limitation)
• Loopback atrfs

[Jacques]

Sounds like a really useful tool, would it work on MacOS X PPC?

 

A little off-topic:
does anyone know a program for ATR-manipulation  for AmigaOS or MorphOS? It would be great to have a MakeATR (Windows) counterpart, there

[pcrow]

On 9/11/2023 at 4:10 AM, Piotr D. Kaczorowski said:

have a small request, if possible. Could you please add the LiteDOS filesystem? LiteDOS is a compact DOS created by Mr. Atari. 

As I recall, it has a filesystem similar to DOS 2.0 but with more space. It's crucial to have both read and write access.

Done!  I just pushed the change.  It has had very minimal testing, so let me know what bugs you find.  Remember to always keep a backup of your original files in case my code corrupts your files.

 

It's fun seeing new DOS versions and noting the design decisions.

[pcrow]

To-do list:

• Find any differences between SpartaDOS versions.  I believe sdfs 2.1 (SpartaDOS X) bumped up the directory entry limit, but I'm not clear on differences besides that with sdfs 1.1 and sdfs 2.0.
• Develop a test suite to find bugs
• Write support for Atari DOS 3 and Atari DOS 4 (why not?)
• Support for other file systems
• Support for any specific game disks where it would be useful
• A script to create a mirror of a file system with atrfs mounts for all ATR files
• Perhaps a fsck tool to check for corruption prior to mounting
• More extensive magic files
  • Add more file information when adding ".info" to file names
  • Maybe disassemble boot sectors

[+x=usr(1536)]

15 hours ago, Jacques said:

would it work on MacOS X PPC?

Maybe.  Try building it and see.  My gut feeling is that there will be compiler / library issues.

 

Out of curiosity, the last version of OS X that supported PPC was 10.6, and that was well over a decade ago.  Why are you looking at it as a target?

[phaeron]

10 hours ago, pcrow said:

I believe sdfs 2.1 (SpartaDOS X) bumped up the directory entry limit, but I'm not clear on differences besides that with sdfs 1.1 and sdfs 2.0.

SDFS 1.1 has a reserved area for DOS, while the sector count byte for it is ignored in SDFS 2.0 and repurposed in SDFS 2.1. It doesn't matter for normal access but needs to be taken into account when validating or recalculating the volume bitmap.

 

[Jacques]

8 hours ago, x=usr(1536) said:

Out of curiosity, the last version of OS X that supported PPC was 10.6, and that was well over a decade ago.  Why are you looking at it as a target?

Because of MorphOS, I own PowerBook G4, on which I have MacOS X PPC 10.5.8. installed as well.

In general, our hobby is related to decades-old hardware

[+x=usr(1536)]

3 hours ago, Jacques said:

Because of MorphOS, I own PowerBook G4, on which I have MacOS X PPC 10.5.8. installed as well.

In general, our hobby is related to decades-old hardware

Makes more sense now 

 

Thing is, without a recent PPC build of macFUSE it's a moot point, since atrfs requires macFUSE in order to mount and manipulate images.  Might want to ask around on the various Apple-centric PPC forums out there to see what would be involved in making it happen.

[Piotr D. Kaczorowski]

18 hours ago, pcrow said:

Done!  I just pushed the change.  It has had very minimal testing, so let me know what bugs you find.  Remember to always keep a backup of your original files in case my code corrupts your files.

 

It's fun seeing new DOS versions and noting the design decisions.

Awesome! I will speak with Mr. Atari, and we will conduct tests.

 

 

 

[Piotr D. Kaczorowski]

 

I have an older Mac running OS X El Capitan (OSX 10.11.6)

 

Here is comment in fuse.h

 

 * IMPORTANT: you should define FUSE_USE_VERSION before including this
 * header.  To use the newest API define it to 26 (recommended for any
 * new application), to use the old API define it to 21 (default) 22
 * or 25, to use the even older 1.X API define it to 11.
 

I tried to compile using both 25 and 26, which correspond to the old and new API versions. In both instances, the compilation was successful. However, I did have to modify 'atrfsc.c', changing 30 to 26.

 

 

 

#if (FUSE_USE_VERSION >= 26)

                   , NULL

#endif

 

----

 

I almost succeeded in mounting the atr file to the filesystem:

 

$ mount

..

..

..

..

atrfs@osxfuse0 on /Users/piotr/Downloads/LiteDOS-SE/atr1 (osxfuse, nodev, nosuid, synchronous, mounted by piotr)

 

As you can see, I'm using FUSE version 3.10.4 for OSX (FUSE for macOS 3.10.4).

Unfortunately, the mounted directory isn't functioning. I receive an 'Input/Output Error (5)' when I attempt to access it.

 

 

Do you have any suggestions on how to resolve this issue?

 

 

 

 

[pcrow]

I adjusted the define as you suggested.

 

When I use this, I don't use "mount' to mount the image.  I run 'atrfs' with the options, and it does the mounting.  I turn on debugging, so I typically run:

 

atrfs -f -s --atrdebug --name=images/testimage.atr ./mnt

 

That mounts ./images/testimage.atr on ./mnt which I've previously created as an empty directory.

[Piotr D. Kaczorowski]

8 minutes ago, pcrow said:

I adjusted the define as you suggested.

 

When I use this, I don't use "mount' to mount the image.  I run 'atrfs' with the options, and it does the mounting.  I turn on debugging, so I typically run:

 

atrfs -f -s --atrdebug --name=images/testimage.atr ./mnt

 

That mounts ./images/testimage.atr on ./mnt which I've previously created as an empty directory.

 

atrfs -f -s --atrdebug --name=a.atr atr1 > log.txt 2>&1

 

 

$ ls

DOS XE 1.0.atr atrfs.prev

LiteDOS manual.pdf b.atr

LiteDOS-SE (build 2022-02-07).atr c.atr

TBasic UBasic (No DOS).atr log

a.atr log.txt

atr1 test.sh

atrfs

[eightcore: ~/Downloads/LiteDOS-SE]

$ cd atr1

-bash: cd: atr1: Input/output error

 

 

 

log.txt

Edited September 13, 2023 by Piotr D. Kaczorowski

[+x=usr(1536)]

Been doing some testing of various sizes of disk images.  So far, this has meant 1440, 2880, 5760, 11520, and 23040 sectors at 128, 256, and 512 bytes each.  Spreadsheet attached with results; secsize.zip contains the test images.

 

Images were created with `atrfs --create --name=number_of_sectors.atr --sectors=number_of_sectors --secsize=128|256|512'.

 

Can't create (yet) images with sector sizes above 512 bytes; I'm guessing that this will change once DOS3 support makes it in.

 

Mounting of images was done with `atrfs --name=number_of_sectors.atr /Volumes/number_of_sectors'.  Messages in the spreadsheet occur after attempting a mount with those parameters.

 

Upon successful creation of an image with no mount point specified, it might be a good idea to exit cleanly rather than allowing the `fuse: no mount point' error to appear; this may cause confusion for some folks since the image was created despite not being mounted.

 

The addition of a --i option would be appreciated.  Think of it as working akin to ffmpeg's -i option in that it would display information about an image; usage would be something along the lines of `atrfs --i --name=whatami.atr'.  Or maybe just `atrfs --name=image.atr' with no other options specified?

secsize.zip atrfs disk capacity testing.xlsx

[Piotr D. Kaczorowski]

@pcrow

 

I've checked the sources. I'll likely add more DEBUGs to the code either tomorrow or on Friday to identify the issue.

[+x=usr(1536)]

28 minutes ago, pcrow said:

When I use this, I don't use "mount' to mount the image.  I run 'atrfs' with the options, and it does the mounting.  I turn on debugging, so I typically run:

 

atrfs -f -s --atrdebug --name=images/testimage.atr ./mnt

Just FYI: running atrfs without any options says that debug is -d.  No mention is made of --atrdebug.

[pcrow]

2 hours ago, x=usr(1536) said:

Just FYI: running atrfs without any options says that debug is -d.  No mention is made of --atrdebug.

Fixed!

[pcrow]

2 hours ago, x=usr(1536) said:

Upon successful creation of an image with no mount point specified, it might be a good idea to exit cleanly rather than allowing the `fuse: no mount point' error to appear; this may cause confusion for some folks since the image was created despite not being mounted.

Good idea.  Done.  I also now allow you to drop the '--name=' but only if doing both name and mountpoint.

So:

  atrfs image.atr mountpoint

works.  I like that a lot because tab completion doesn't work with the '--name=image.atr' syntax.

[pcrow]

2 hours ago, x=usr(1536) said:

Can't create (yet) images with sector sizes above 512 bytes; I'm guessing that this will change once DOS3 support makes it in.

I thought DOS 3 was only 128 bytes.  DOS 4 is only 128 and 256 bytes.  I'm under the impression that SpartaDOS is the only one that supports 512-byte sectors, and nothing does larger that I'm aware of.  Please correct me if I'm wrong on this.

 

Speaking of sector sizes, do all DD drives return only 128 bytes for the first three sectors?  I was always envious of my friends who had them.  Media with 512-byte sectors doesn't do anything weird like that.  My understanding is that ATR files for 256-byte sector disks can contain only 128 bytes for the first three, or they can do 256 bytes for all.

 

I don't think I thought much about creating 512-byte images for SpartaDOS, but obviously I should.

[+x=usr(1536)]

21 minutes ago, pcrow said:

I thought DOS 3 was only 128 bytes.  DOS 4 is only 128 and 256 bytes.  I'm under the impression that SpartaDOS is the only one that supports 512-byte sectors, and nothing does larger that I'm aware of.  Please correct me if I'm wrong on this.

Nope, you're correct.  I mixed DOS3 block sizes and sector sizes together in my head.  Apologies for any confusion.

 

[_The Doctor__]

Bytes can be available but only 128 will be read by most drive on the first 3, as that's what standard for Atari mostly.

[pcrow]

4 hours ago, x=usr(1536) said:

The addition of a --i option would be appreciated.  Think of it as working akin to ffmpeg's -i option in that it would display information about an image; usage would be something along the lines of `atrfs --i --name=whatami.atr'.  Or maybe just `atrfs --name=image.atr' with no other options specified?

Done.  It does require specifying --info or -i (the help only lists the long version).  It is mostly just what is in the .fsinfo file already, but it also points out what the ATR header says about the size of the image, and what the actual file size suggests if it's different, as I've seen several images where the file size is longer and the header is most likely wrong.

[Piotr D. Kaczorowski]

A use case consistent for many years with Unix systems:

 

mount_atr montezuma.atr /mnt/atrdisk1

 

So, mount_atr corresponds to atrfs, but in principle, you shouldn't add --name. Personally, I would replace name with "--src", although this would mean that when creating disks it should be "--dst". However, if a token in the arguments has the ".atr" extension, it should be treated as "--name=....atr".

 

All in all, it's just a cosmetic touch at the end, once other more important issues are resolved.

[Piotr D. Kaczorowski]

A small request that will enable debugging under different systems with different versions of libraries. It shouldn't be too complicated and probably won't take much time, but it can help many times.

 

Please consider to add a "--dummy" option, e.g. "atrfs --dummy /mnt/atrdisk"?

 

The goal is to test-install a virtual ATR, which will return a short list of files, or for files, it will return the content "hello world", allow copying a file to the virtual disk - but only this will create a file that will contain "hello world". Such a thing will make it easier to add DEBUG and determine incompatibility with a given system or fuse library.

 

In the future, the fs layer could be divided into two layers. The lower one would simply work generically, and the higher one, interfacing with the FS library, would have all the options/pragmas related to a specific version of fuse or another library that would allow the implementation of a virtual FS.

 

I know that, unfortunately, this would require a thorough rewrite, as it's a change at the design level.

[pcrow]

8 hours ago, Piotr D. Kaczorowski said:

A use case consistent for many years with Unix systems:

 

mount_atr montezuma.atr /mnt/atrdisk1

 

So, mount_atr corresponds to atrfs, but in principle, you shouldn't add --name. Personally, I would replace name with "--src", although this would mean that when creating disks it should be "--dst". However, if a token in the arguments has the ".atr" extension, it should be treated as "--name=....atr".

 

All in all, it's just a cosmetic touch at the end, once other more important issues are resolved.

Yes, I had realized that, too.  The '--name=' is now optional for general usage, but is still needed if you're just using --create without a mount point.  Since it does more than just mounting, I'm leaving renaming as an exercise for the user.  (You can --create without a mount point, same with the new --info command.)

[pcrow]

8 hours ago, Piotr D. Kaczorowski said:

In the future, the fs layer could be divided into two layers. The lower one would simply work generically, and the higher one, interfacing with the FS library, would have all the options/pragmas related to a specific version of fuse or another library that would allow the implementation of a virtual FS.

 

I know that, unfortunately, this would require a thorough rewrite, as it's a change at the design level.

The code mostly keeps all the FUSE stuff in atrfs.c.  There is one struct pointer type passed through to other modules (easily addressed without FUSE libraries).  The only thing really from FUSE used in the code for specific file systems is the filler() function pointer for filling in directory entries.  Again, I could make this a void pointer, and then call a filler function in atrfs.c that uses the type from the FUSE library to call the function.  With that, there would be no FUSE includes or defines needed except in atrfs.c.  Oh, and there's the change from utime() to utimens() that would require a wrapper in atrfs.c for SpartaDOS and DOS XE.  I've been thinking it would be nice to get FUSE isolated to atrfs.c.

 

The other related issue would be the Linux flags for the rename feature, but I think that's fairly cleanly handled.

 

My strategy was to put any needed customization into the Makefile.  If this were to get more complicated, that would be pushed back to autoconf, but that seems like overkill here.