Re: gmc/libvfs suggestion for removable media



For the Love of BOB NO!!! :)
If anything like this is to be done it should be done by the kernel/mount.
Spending alot of time to make removable media work in only gmc and mc
seems alittle like a wast of time. Maby have a mount switch that tells the
kernel to allways write to a device on change and mount the device instead
of the filesystem. This would allow for the flexibility you request and
allows all programs to work with it like DOS did.

With the above description if /dev/fd0 was mounted to /mnt/floppy, 
/mnt/floppy would act like A: in DOS

On Mon, 22 Feb 1999, Daniel Burrows wrote:

>   I apologize if this is already in gmc or done (done _better_ that is) in
> some other program or a feature of Linux that I missed somehow. :-)
>   Also, my understanding of libvfs is incomplete, this may be an incorrect
> use of it.  But the problem is still there and I think that a solution
> that at least works for Gnome apps would be in order.
> 
>   It occurs to me that Linux's handling of removable media, while certainly
> good technically, leaves a lot to be desired in terms of usability.  It's
> not just that users have to explicitly mount floppies, somewhat more
> annoying is the fact that they have to umount them before doing anything
> else with the drive.  To an extent, adding sync to the mount options in fstab
> helps, but I think that there may be better solutions.  Here's what I was
> thinking (this is almost certainly not a 1.0 option and I readily admit that
> I probably wouldn't be able to implement this, it's just a proposal of a
> feature.  Of course, if I get some time to learn how to implement it.. ):
> 
>   Add a "removable" VFS type in libvfs.  This type would be used for devices
> which could be removed and vanish at any moment (like floppies).  Data would 
> be synced to the disk when written and sudden removal would be handled fairly
> nicely (eg pop up a warning dialog and maybe let the user reinsert the disk and
> continue--the last might be difficult depending on how it's implemented)
> 
>   The two implementations I can think of are either 'automounting'--mount the
> media when it's accessed, do stuff, and umount it--or 'raw'--directly access
> the device. (like mtools).  Probably automounting is the best solution for
> now; in addition to being simpler to implement, it can be done by normal users
> if root adds "user" to the options in the fstab. (also we can get synchronous
> data transfer with the 'sync' option but I don't think I'd rely on that..it
> also doesn't solve the problem of the user removing a mounted disk)
> 
>   This'll work for moving stuff around in gmc; I think some trickery may
> be involved in actually accessing files for programs.  I don't know enough
> about libvfs :-( but I believe that it must redirect read(), write(), seek(),
> etc requests in order to work?  Probably the best way to do it then would
> be to wrap all requests with mount/umount calls, and prompting the user (using
> callbacks so console apps can prompt in the console and Gnome apps pop up
> a dialog box) when the disk isn't available.
> 
>   Another useful thing might be to somehow ID disks somehow (serial number? Can
> a non-privileged process get that?) to detect 'disk switches' and even allow
> two separate removable VFSs to be open at once (for example, I open a VFS
> on one floppy and another on another floppy, then copy a file from one floppy
> to the other..the VFS asks me to insert each floppy at the appropriate time).
> 
>   Of course, it's possible that no-one uses floppies anymore and this is
> a useless suggestion. :-)
> 
> -- 
> "It is hard to think of anything less sentient than a pumpkin."
>   -- Terry Pratchett, "Witches Abroad"
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
> 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]