RE: [MiNT] Mount and MiNT

["Julian Reschke" <reschke@muenster.de>]

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Mario Becroft
> Sent: Friday, August 06, 1999 10:41 AM
> To: mint@fishpool.com
> Subject: RE: [MiNT] Mount and MiNT
>
>
> On Fri, 6 Aug 1999, Julian Reschke wrote:
>
> > I remember an early Mac emulator on the Atari which would start
> flashing the
> > drive and beeping if you removed an unsynced medium. This
> behaviour could be
> > implemented trough an XHDI driver for floppies, if you really
> want that...
>
> I didn't suggest anything like this, but only that the floppy disc cannot
> be locked so therefore the argument about locking the device appears to me
> to be irrelevant in this case.
>
> > a) a problem of the program accessing U:, and
>
> What do you mean? Lots of programs access drive U, for example ls when I
> type "ls /", bash when I use filename completion on a file in drive U, the
> desktop when I open a window showing drive U, the fileselector when I do

Yes, but just using Dreaddir() on U: will NOT cause a floppy access.

> the same ... I try to avoid this by never accessing anything via drive U,
> but instead via the drive it is actually on, but in that case why have
> this drive U at all? However it seems that UNIX-like programs under MiNT
> always access everything via drive U, so it's not possible to put
> everything on another drive and not use drive U). Even if it is, you would
> need symbolic links to the proc, shm etc directories, and then when you go
> into one of these directories and out of it again, you are quite likely to
> end up in the place where the original file is, namely drive U, and so in
> the end it is not possible to avoid using drive U at all.
>
> But maybe there is some other way of not using drive U which I don't know
> about. Like I said, I am not so very well informed about this.
>
> > b) wouldn't be such a problem if MiNT would have background DMA.
>
> Except that MiNT doesn't have background DMA, so this doesn't help much...
>
> > Nobody prevents you from removing the drive bit when you eject the disk.
> > Just write a program which does just that and call it umount.ttp.
>
> Well, I didn't realise that it was appropriate to do this while the
> computer is running but I suppose this would largely fix the problem.
> It's funny that nobody ever mentioned this before.

There are even programs out there to remove the drvbit for drive B: -- just
for that reason...

>
> I think there is still a slight problem in that the program would always
> have to sync the disc before removing the drive bit, and it is just
> possible that something would write to the disc between when it was synced
> and when the drive bit was to be removed, but I suppose this is uncommon.

Not if you out everything together into supervisor mode.

> I still see problems with this arrangement, but maybe there are yet more
> kludges which I have not thought of for avoiding these problems.
>
> For example if a disc has an error and I want to repair it, how do I go
> about "unmounting" the filesystem in question so that the error can be
> repaired by an automated program or by hand, without interruptions by
> other programs accessing the drive? How can I make a drive become read

This is not possible. Dlock() it -- then all GEMDOS calls will fail, but
your process is free to access the medium directly.

> only so that no data can be written to it and it can be modified by a disc
> editor, or the computer switched off, without fear of damaging the
> filesystem?