Floppy Driver Update Ready For Linux 6.2 - Still Being Maintained In 2023

[ssokolow]

You can do that, but it's not nearly as convenient as simply mounting the floppy to the filesystem as a drive.

It's not meant to be. It's what's known as an "archival/forensic" floppy controller... a class of devices which prioritize things like write-protect jumpers and being able to make low-level flux images of disks to preserve things like copy protection schemes intact for future analysis and/or authentic emulation.

...something which I like, since I never have to worry about a Thumbs.db or .DS_Store or .directory or changes to file metadata trashing pristine-ness of a vintage disk where the publisher didn't bother to get disks with the write protect slider omitted and someone (eg. my young self) used it as a fidget toy.

[Developer12]

It's not meant to be. It's what's known as an "archival/forensic" floppy controller... a class of devices which prioritize things like write-protect jumpers and being able to make low-level flux images of disks to preserve things like copy protection schemes intact for future analysis and/or authentic emulation.

...something which I like, since I never have to worry about a Thumbs.db or .DS_Store or .directory or changes to file metadata trashing pristine-ness of a vintage disk where the publisher didn't bother to get disks with the write protect slider omitted and someone (eg. my young self) used it as a fidget toy.

People don't need this for archival or forensic purposes. They need to mount the floppy disk and copy files across. That's why they need continued support for floppy drives.

[ssokolow]

People don't need this for archival or forensic purposes. They need to mount the floppy disk and copy files across. That's why they need continued support for floppy drives.

*nod* I'm just saying that it's less convenient because that use-case isn't what those things are designed for. It's like complaining about the gas mileage of a big, heavy industrial haulage vehicle when you're using it as a residental vehicle. Sure, you can do it... but you have no right to then complain about it.

(In other words, I did a sloppy job of elaborating on your argument. I didn't meant to dispute it.)

[willmore]

ssokolow Developer12 I think you're both ranging away from my point. I agree that having a working driver is good thing. My assertion is only that you do not have to have an older system with a floppy controller in it to be able to read and write floppies. Yes, the workflow is different, you're not just inserting the media, mounting it, reading/writing/modifying what you need, and unmounting it. You have to image the media, convert it to a block file image of the media, mount that on the loop interface, then do your read/write/modify step, unmount the loop, convert the image back to flux, write the physical media. Nothing that can't also be automated with a script.

If you're moving the disc back and forth daily, this will be a bit of a burden, but if you're doing that, you really need to look into a hardware floppy emulator because the amount of wear you're putting on that system will cause it to fail. But, in the case if needing to deal with a floppy monthly or annually, this method would be just as easy and probably superior as the whole media gets rewritten and there's no jitter between the sector headers and the data because the image gets written 'perfect' instead of how it happens with a floppy controller on a physical drive.

[Developer12]

ssokolow Developer12 I think you're both ranging away from my point. I agree that having a working driver is good thing. My assertion is only that you do not have to have an older system with a floppy controller in it to be able to read and write floppies. Yes, the workflow is different, you're not just inserting the media, mounting it, reading/writing/modifying what you need, and unmounting it. You have to image the media, convert it to a block file image of the media, mount that on the loop interface, then do your read/write/modify step, unmount the loop, convert the image back to flux, write the physical media. Nothing that can't also be automated with a script.

If you're moving the disc back and forth daily, this will be a bit of a burden, but if you're doing that, you really need to look into a hardware floppy emulator because the amount of wear you're putting on that system will cause it to fail. But, in the case if needing to deal with a floppy monthly or annually, this method would be just as easy and probably superior as the whole media gets rewritten and there's no jitter between the sector headers and the data because the image gets written 'perfect' instead of how it happens with a floppy controller on a physical drive.

Is it possible to read/write files in this way? yes. Is it convenient enough to inflict this on your employees? no.

If you go waaaaaaay back to my original post, you'll note that I gave another solution: A "chain of fools" where you use a string of two or more computers (of varying age) to copy files onto and off of the disk, shuffling between multiple formats.

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1360535-floppy-driver-update-ready-for-linux-6-2-still-being-maintained-in-2023?p=1360545#post1360545

The fundamental requirement (as I discussed) is to have people copy files onto and off of floppy disks for running vintage equipment when the files are present on modern IT infrastructure. Being able to insert the floppy into a mid-2000s machine with a native floppy drive, running a modern OS, and just drag the files across is the optimal solution. It however requires working drivers.

While there are LOTS of ways it's *physically* possible to put some files on a floppy disk, a chain of fools and complicated floppy imaging equipment both fail the human factors requirement.