Centuries ago, Nostradamus predicted that Sylvain Saboua would write on Mon Nov
4 04:04:58 2024:
>
> About one week before when I woke up I saw that most of the files
> from my /mnt hard drive had disappeared. Public and personal
> archives, media collection... Nothing shows up anymore. 'du -sh'
> command displays free space, however the space is still used up as
> per 'df -h' command.
>
> #pwd ; du -sh . ; df -h | grep -E 'Used|fusefs'
> /mnt 122G .
> Filesystem Size Used Avail Capacity Mounted on
> fusefs 3.6T 3.3T 328G 92% /mnt #
>
> Is there a way to diagnose the issue, and to keep/recover the
> (apparently still present) files ?
>
If a program opens a file and then deletes it (and it has no other
names), it is not deallocated until it is closed, either explicitly or
implicitly (by, e.g., the exit system call). Since it has no name, it
is not found by du; since it is not deallocated, the output of df is
unaffected. The fuser command (if that is implemented in OpenBSD)
will tell you which processes have open files in a filesystem. You
can recover such a deleted file only by persuading the still-running
process that has it open, to recreate it, and write the contents of
the still-open file onto the newly-created one.
The same is true, mutatis mutandis, if a file is not open, but is in
use for some other reason (e.g., it is an executable program that is
still running, or a shared library used by such a program, or if it is
memory-mapped, or if it was passed as the argument to the pacct system
call, et cetera). It is not deallocated until it is no longer in use.
(Also, since this is a fusefs filesystem, of a type that you do not
reveal, it is always possible that there is some bug in the filesystem
implementation.)
> --
> Sylvain Saboua
> www.saboua.xyz
>
Jay F. Shachter
6424 North Whipple Street
Chicago IL 60645-4111
+1 773 7613784 landline
+1 410 9964737 GoogleVoice
http://m5.chicago.il.us
j...@m5.chicago.il.us
"But when she traced the killer's IP address ... it was in the
192.168/16 block!"
