On Wed, Feb 08, 2023 at 05:59:12PM +0100, Peter N. M. Hansteen wrote:
> On Wed, Feb 08, 2023 at 04:50:32PM +0100, Jan Stary wrote:
> > On Feb 08 13:56:18, pe...@bsdly.net wrote:
> > > 1) close any open files stored there
> > > 2) make sure no process has the media as $PWD (as in, cd away from there,
> > > and really a variation on the first)
> > > 3) issue at least one sync command (some folklore will insist on three)
> > > 4) umount the media from wherever it was mounted
> >
> > 4 takes care of 1,2,3, right?
>
> It is a common assumption it does,
It certainly does the sync, from /src/sbin/umount/umount.c:
int
main(int argc, char *argv[])
{
int all, ch, errs;
/* Start disks transferring immediately. */
sync();
> but I have seen time and again applications
> either coredumping and hanging while doing so or just getting terribly
> confused
> when their presumed current directory disappeared from under them.
>
> Depending on how much force you put behind the umount (as in doas, sudo) it
> is not entirely certain you would be able to umount a file system that has
> open files.
>
> Then again, your mileage may vary. And the OP asked for safe removal.
I interpreted 'safe removal' as meaning that the data on the removable storage
is
kept intact.
If a userland program crashes or mis-behaves when a device is removed, then that
is really an issue specific to that program, and a somewhat different
discussion.
If unmounting a device, (and detaching any associated softraid device if there
is
one), is not enough to ensure that it's contents matches what the system
believed
it had written to it, then there is surely a kernel bug somewhere, (or a
hardware
issue).
