-----BEGIN PGP SIGNED MESSAGE-----
One thing that most users have been trained to avoid is removing the
floppy while the light is on (still spinning) so if we can set that it
will avoid most problems.
David lang
On Tue, 13 Jun 2000, Steve Holdener wrote:
> Date: Tue, 13 Jun 2000 11:05:57 -0500
> From: Steve Holdener <steve.holdener@wwt.com>
> To: linux-kernel@vger.rutgers.edu
> Subject: Re: Floppy Handling
>
> Quoth Billy Harvey:
>
> - What is needed is a program which when called will dd the image of the
> - floppy just inserted into a file, in some specified location, perhaps
> - /var/floppy-`date +%s`, for example. with ownership assigned to
> - whomever did the calling.
> -
> - Once the dd is complete, the floppy must be removed, this file is then
> - mounted using loopback. Removal of the floppy will force the newbie
> - to realize that the data being operated on is not physically on the
> - floppy.
> -
> - Once the work is complete, there is a similar reverse process, which
> - can check to ensure that either a blank floppy or the same floppy is
> - used, that will call for the floppy to be inserted, and then will
> - dd the file back to the floppy, and then call for it to be removed.
> -
> - The image file can then be either automatically umounted and deleted,
> - or alternatively marked in some way so that if it is kept mounted and
> - further written to, it will be considered dirty, annotating a need for
> - a further sync to the floppy.
>
>
> I like the idea, but the dd takes too long. I'd hate to wait for 1440K to transfer just so I can access a 1K file--on read AND write. Perhaps if the file could be opened immediately so the user can get working and the dd is run in the background...It still seems like a lot of work. And what if the user did want to read off one disk, edit, and write to a new disk?
>
> It strikes me that, to be consistent with the typical conceptual model a user has of the floppy, it might be more appropriate to perform a mount/read/umount to open a file. Saving a file would, of course, be a mount/write/umount procedure. This makes removing/swapping floppies between opens and saves safe and does so w/o any (much?) added complexity.
>
> There is, certainly, the drawback that buffering writes to the disk becomes ipossible. But it achieves *predictability* for the user.
>
>
> -Steve Holdener
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
iQEVAwUBOUZxfD7msCGEppcbAQEdRAgAxT0oE7royCCvaYOoYu7lxZGT4APIsfDw
YBTHA5rmSv4vtUD8LWUwYaH1ctocivXdb8P5CSVNtece28u0c419i/eWga/il693
PU2+XXgalBGoBfLFpTi4kDPnnWG1vdLoq0RCkUBxHpEd9d//D5KPK0VqkUzYh+bm
uoMCnpsLeXyvBTLDbl6yt8KvTODNdMVg+bLK6YSPFehWvvjSaDOWp0PAGLEL+DY7
d2a+B0kcRbWAfSg+VThFyctf/os93geAEREQyAQ+M8SLSQ9uH7q/B2MuntpAoZdQ
HX7srXV6AxHmAUDRjq0ehJtaawOALs2c9rNsNdrEqJoZiBDEmQvlEg==
=sajR
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:28 EST