fs/adfs on Linux - keep or kill it?

Just received this email from Russell King – ARM Linux admin <linux@armlinux.org.uk>.

If you wish to continue to use the ADFS filesystem going forwards on Linux, please read and reply to him on the above email address.

BTW I have no interest in further enhancing (or maintaining) it! I submitted some patches a while back as I wanted to copy the contents of an ADFS-formatted IDE drive over into a Linux-based RPCEmu a couple of times.

Hi,

Recently, a couple of issues have been identified in fs/adfs:

1. Filename truncation may not work as it should, and Linus has
apparently expressed a desire to kill this off.

2. Scanning the ADFS map for disc object fragments may mistakenly
find free space fragments in addition to real disc object fragments,
leading to chunks of free space appearing in files or directories.

No one has reported any issues with the filesystem module, so the
question has to be asked whether there are any users of this code?

I’m aware that there were some users about ten or more years ago. I’ve
only touched it when problems have been reported to me that needed me
to investigate something, otherwise I haven’t used it myself – so the
code largely just sits there, mostly untouched except for the odd
cross-filesystem patch.

The last “feature” patch was in 2011 by Stuart Swales (copied) adding
the filetype suffix to filenames.

That leads on to the question about whether this should be fixed in
mainline or whether we should put the code out of its misery and remove
it from the kernel.

Fixing both issues is fairly trivial, and I already have some fixes
available, along with some improvements to the rest of the code.
However, I see little point in pushing that upstream if the code is
not being used.

Searching the web, there does seem to be some interest on some forums,
but that dates from about three years ago, but it also seems that more
functional solutions (using fuse, with different format support) are
available.

Posting to Linux lists probably isn’t the best way to find out whether
there are users of this, so if there are people involved in the Acorn
communities, please pass this on to more appropriate forums, thanks.
Please ensure that replies reach me as I don’t monitor random web
forums for example (a reply on a web forum that I don’t see is not
helpful.)

If I hear nothing positive towards keeping it, then I’ll schedule
fs/adfs for deletion, probably for 5.3.

Thanks.

Since the RISC OS FileCore implementation is now using the Apache license, my feeling is that the correct way forward would be to rewrite RISC OS FileCore in C, and then use that as a basis for providing FileCore implementations for other OS’s.

Of course, we’d still need to find someone with enough time on their hands to rewrite ~47000 lines of assembler in C :-)

@Jeffrey: The Linux implementation surely is written in C.
I still use this for accessing both ADFS disks, USB sticks (old copies) and ADFS images stored on my NAS.
Using it write-only has helped me many times after accidentally trashing a disk with some tests on RISCOS emulators or RISCOS on Linux related work.

@Stuart: I am interested in the fixes and also wonder if those fixes also improve stability of writing to the ADFS images. If we can improve RISCOS integration in Linux we may find the kernel module quite useful. Keeps me voted for ‘keep this module’.

I would vote to keep it and improve it too.

My main logic here is that most boards that run RISC OS now were actually created with Linux in mind – Pi, Beagle, Panda, Wandboard even Pinebook. Switching to run linux is as simple as changing the OS card. As such, being able to mount ADFS discs (eg. USB drives) is something that is very practical – just swap your Pi’s OS card for a linux one and all your RISC OS format discs remain accessible.

Please ensure that replies reach me as I don’t monitor random web forums for example (a reply on a web forum that I don’t see is not helpful.)

Do please feed back direct to Russell King at the address Stuart gave above.

I’ve copied Russell in on the replies to date but please do let him know directly too. I agree with Andrew that a multi-boot RISC OS / Linux system sharing devices is a very valid use case.