Well actshly, rm removes the inode, not the file. If it’s still in use it’ll stay on the disk until the last fd is closed.
- with most file systems that are usual on linux
Yep, it’s a smart system.
For the user, the file is immediately no longer in the tree, so for them it’s considered done.
The OS should handle all the hassle, not the user.I think “consider it done” puts it well.
“I’ll get to it, eventually” would ruin the meme but be more fitting, in my opinion.
Had multiple occasions where people fought against filling disks and just couldn’t see why. Well, that 10 gig log file you deleted two weeks ago? It’s 20 gig now, and still being written to.
lsof shows stuff like that.
Do modern file systems actually remove it from disk? It’s been a while since I did any forensics and didn’t do much of it, but I remember being able to batch restore files from inodes as long as that part of the disk hadn’t been overwritten. That’s why you’re supposed to overwrite disks with random data if you want to data gone.
Nah, they just throw away the block markings, absolutely.
Overwriting a SSD is difficult as well, better encrypt the drive and trash the key when you decommission.
What about microwaving it?
You mean like in your kitchen? Too much metal, you’ll damage your magnetron.
You could use thermite and melt it to a pulp. Dangerous as well, though.
Really, just encrypt. Your CPU has AES extensions, performance impact is negligible. Simple, clean, and a protection against involuntary decommission as well.
Overwriting a SSD is difficult as well,
Trim does a pretty good job actually. Secure erase as well.
https://rossmanngroup.com/technical-reference/what-trim-does-and-why-it-destroys-data
better encrypt the drive and trash the key when you decommission.
Absolutely.
I’ve had to RMA defective HDDs, and was glad I didn’t have to think about what kind of data was still on the platters.
SSDs and HDDs don’t always completely fail either. I’ve had a case where the drive could still be read, albeit very slowly. Writes were not working. Kinda sucks if you wanted to empty the drive before handing it in for repair/replacement.
I keep seeing things about inodes lately. Can you ELI5 for a novice? Where are the inodes? Are they in the room with us now? 👀
Extremely simplified:
Your file system consists of a whole lot of blocks to write data to. Let’s say you have a block size of 512kB, so a 4MB file would span 8 blocks. A 3.7MB file would span 8 blocks, too, as the remaining space can’t get used otherwise.
Now to get what file exists on which blocks, there’s a large index table, consisting of a number of index nodes (shortened to inode). Each inode saves multiple data fields of a file, like its name, owner, creation data, and the files blocks.
If you link a file to a second name (hard link) a second inode will get created that points to the same blocks.
That’s about it. Used to be important to chose the right inode size and count on filesystem creation for the average data you’ll save on the filesystem, as inodes have a fixed count, and the index table takes disk space, too. Too many inodes and you waste space that you could use for precious data, too few inodes and you can’t save new files even when you have free data blocks. With growing disk sizes people just went with massive indexes, who cares about a few wasted megs.
Modern filesystems (like ext3 and up) introduced journals, which complicate things.
Thank you so much for taking the time to explain it. Actually makes sense.
You can also still access the file as long as there’s a process that still has it open. I have, in the past, “undeleted” a file or two doing that.
$ echo foo > bar $ tail -f bar fooIn another terminal:
$ pidof tail 1525534 $ ls -l /proc/1525534/fd|grep bar lr-x------ 1 tal tal 64 Jun 16 06:42 3 -> /home/tal/bar $ rm bar $ ls -l /proc/1525534/fd|grep bar lr-x------ 1 tal tal 64 Jun 16 06:42 3 -> /home/tal/bar (deleted) $ cat /proc/1525534/fd/3 foo $ cat /proc/1525534/fd/3 > bar-recovered $ cat bar-recovered foo $That is, the /proc entry for tail’s file descriptor 3 there looks kinda like a symlink, but the kernel doesn’t actually make it behave in quite the same way as a normal symlink.
That being said, getting back to the original point about unlinking not being able to remove the directory entry…it won’t sit there blocking you from putting a new directory entry there with the same name, the way Windows file semantics mandate.
EDIT: Also, what
rmremoves is the directory entry rather than the inode. The inode sticks around as long as the file data is there. You can have multiple directory entries for an inode, or none at all, but file data will have an inode associated with it.$ touch a $ sudo ln -T a b $ stat -c %i a 216538023 $ stat -c %i b 216538023Same inode, different directory entries.
https://en.wikipedia.org/wiki/Inode
inode persistence and unlinked files
An inode may have no links. An inode without links represents a file with no remaining directory entries or paths leading to it in the filesystem. A file that has been deleted or lacks directory entries pointing to it is termed an ‘unlinked’ file.
Such files are removed from the filesystem, freeing the occupied disk space for reuse. An inode without links remains in the filesystem until the resources (disk space and blocks) freed by the unlinked file are deallocated or the file system is modified.
Although an unlinked file becomes invisible in the filesystem, its deletion is deferred until all processes with access to the file have finished using it, including executable files which are implicitly held open by the processes executing them.
I wanted to remove an Adobe file because it wouldn’t let me uninstall Adobe through the program management. It said it was being used. By explorer apparently. Checked online, all I had to do was rename the file, then delete it. Worked. But it’s so dumb.
Btw this also method to prevent file/dir be automatic created: for dir make file with same name, for file other way.
Usually rename only replace other file, not dir. And if path exist but file, cannot open as dir, but also not create.
This was how you could prevent Cortana and some other stuff from being automatically reinstalled when Windows forced if. Uninstall the app via appx, or just delete the folder instead if it’s not in use, and then replace it with a file with the same name so it can’t remake the folder.
Who is using my file?
lsof path/to/fileYou almost always want to pair
lsofwith-n, as by default, it (slowly) lists a bunch of things that require name resolution.$ time lsof >/dev/null real 2m12.352s user 0m0.499s sys 0m1.217s $ time lsof -n >/dev/null real 0m1.600s user 0m0.523s sys 0m1.029s $
Windows being portrayed as a polite UwU in þis meme has always seemed off, to me. I imagine it as more surly and petulant.
I imagine it more as a condescending IT guy who isn’t actually very good at his job and has secretly set up each machine to spy on the users (but again isn’t very good at what he does so it isn’t much of a secret).
Where did I read that the þ character doesn’t really help against AI at this point? That it is pretty futile? Can’t remember.
The trick for windows is to rename the file and kill the process that’s using it / reboot (if it’s some unkillable service). The service won’t then be able to find the file after reatarting and you can delete the renamed copy.
On linux this whole thing is done automatically by the OS: if a file is open and you delete it, it will disappear from the folder but its data won’t actually be deleted from the disk until it’s closed by every program. Some programs even use this trick to create invisible temporary files to offload some data from RAM to disk!
the windows command system is so dumb and unintuitive. what takes like a command and 2 arguments on Windows takes 3 times the effort and an unnecessarily long command syntax
