Re: Floppy handling

From: Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Date: Tue Jun 13 2000 - 07:51:01 EST


Billy Harvey <Billy.Harvey@thrillseeker.net>:
> Richard Stallman writes:
> >> Thats all very nice, but what do you do for the "luser" that opens a file
> >> on the floppy using a word processor... I see that a LOT at work (plus the
> >> use of excel/photoshop/exporer/...
> >
> > When you visit a file with Emacs, Emacs opens the file, reads it all,
> > and closes it. Once that is finished, the file is not open any more.
> > When you save the file, Emacs opens it, writes the whole text, then
> > closes it. So if you removed the floppy after visiting, the save will
> > get an error, but nothing worse will happen. If you replaced it with
> > a different floppy, the save will go on the new floppy.
>
> Your post the other day about this got me to thinking, and the Emacs
> analogy above is similar to my though line and can be extended to
> floppies with (hopefully) little confusion to newbies.
>
> 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.
>
> The value of this is the usual sync and buffer ability of Linux is not
> degraded, and the forced physical removal of the floppy will also
> force a recognition of a need to later synchronize.
>
> Thoughts?

I like most of this idea - This even allows the user to switch floppies
for additional files (more space used in /tmp/xxxx.fd?, where xxxx is
identifier for user, and fd? is a floppy reference) and merge files from
different floppies.

It does mean that the handler process must have access to the user
(via X or command line...) to detect the switch and:

1. be able to put modified file systems back on a floppy
2. allow the restored copy to be put on a different floppy (overwrite backups)
3. be able to format/label the floppy and put a file system on it
4. support multiple file systems

Additional questions:

1. Should this be available to all removable disks?
2. Is this really for only 1.4 MB floppies (those that can't prevent users
   from removing the media while mounted)?
3. Could/should it be used in the creation of bootable floppies (LILO or
   raw kernel)? ((((( my opinion: no - this should be a reserved privileged
                        operation, but it may be desired for support of
                        M$ operationally. ))))

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
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 : Fri Jun 23 2000 - 21:00:11 EST