Mail Archives: opendos/1997/02/14/19:49:42
> > I read something, I think it was the cacher supplied in OD, that when
the
> > prompt is back on the screen, the cache has been dumped.
> > In linux this will be when the process ends I guess.
> > In other words: You play a game from floppy (don't laugh! It's just an
> > example) and you quit, after saving your hi-score ofcourse.
> > The program ends, the cacher get's a signal from the shell(?) and dumps
all
> > delayed-write-stuff to the disk, then gives the user a prompt, which
> > indicated that the floppy can be removed safely.
> > This does not mean however that a floppy cacher is useful :-)
>
> No, that is only useful if you remember to sync the drive, or
> umount it before ripping out the disk.
>
> Consider this.
>
> $mount /dev/fd0 /a -t msdos
> $cp txt/* /a/
> A 3 second wait for a 1.3Mb transfer to floppy.
> Now the drive light is off, and you pull the disk out (like you
> would in DOS). However, the command prompt *IS* back, and the
> cache hasn't written the data to disk. Kiss the disk goodbye.
>
> Also, even if you could make the command prompt come back, this
> would just delay the copy operation so that you'd have to wait
> for it before doing anything else. What? In a multitasking OS?
> Heck, any commands that don't give me my prompt back get shoved
> in the background, so that copy command becomes:
>
> $cp txt/* /a/ &
>
> And the prompt is back.
Yes, but in the text above I said that in Linux (or any other MultiTasking
enviroment for that matter) it's ready when the process ends in stead of
when the prompt is back.
You could have the shell give a message like: "/dev/fd0 can now be removed
safely".
So unless you see that message, do not remove the disk.
Yeep
- Raw text -