Hacker News Reader

Comment by pram | Hacker News Reader

Another useful thing to remember: if you deleted a file and a process still has it open, you can copy it from the file descriptor in /proc! Just use lsof to find the PID and FD. This has saved my bacon a few times in the past ;P

View on HN

Only on Linux, and not everyone who uses Unix uses Linux.

I actually had to recover a deleted file on OSX once. I sure wished the proc filesystem was present there.

I ended up using gdb (or maybe lldb I don't recall) to load a shared object that did a seek()/open()/copy(). Totally hacky but it worked!

Actually /proc was invented on Solaris in the mid-90s.

However this story took place on DEC Unix about 10 years earlier. So /proc was not available.

False, from plan9.

Like with Euler, we generally credit the first one to do it after Plan9.

...and Windows won't let you delete a file that's still in use, so this scenario can't happen.

That is also problematic - and if I recall correctly partly one of the reasons behind why windows requires restarts so frequently when software updates are on the table.

Yes, that is indeed the major pain. Unix-likes have an actual VFS as an API and it happens (at least on every unix-like I've worked on for any bit of time, which is mostly Linux but I expect BSD has it as well) to allow for comparatively wondrous workflows.

Windows programs also often only support 'CDs' (ISO9660 / UDF), FAT, NTFS, and maybe SMB/CIFS (Samba / CIFS) network shares. Since Windows lacks (or at least historically lacked) a general VFS they could target. That's why any actual VFS that ever gets made, due to all the legacy software, is either going to directly support one of those interfaces, or have a compatibility mode which does.

I do wonder why they've not chosen to make progress in that regard to advancing the state of the system. Surely these are known good ideas that would improve the customer experience and the system from a technical level. I only speak as a very casual windows user, there is nuance I will miss with Microsoft's attitudes to it.

I would have thought that even a separation between OS and User applications could allow them to implement features like a VFS, while still maintaining compatibility. Are they not part of the way there with Hyper-V + WSL?

Microsoft would love to do these things, but backwards compatibility guarantees prevent advancement a lot of the time.

You would not believe some of the business critical software out in the field. They rely on very obscure bugs being present in order to function, and they sometimes can't be fixed because the source code is missing.

Apple has chosen the opposite path, which is to give the middle finger to long-term backwards compatibility, and advance their operating systems technically.

You can't run an OSX game from 2002 on the Macs of today, but you almost always can run a Windows game from 2002 on the Windows 10 PCs of today.

The Windows equivalent is IFS, and that has been around since MS-DOS: https://en.wikipedia.org/wiki/Installable_File_System

It has more to do with Windows services and applications (and even the kernel) only reading file contents on initialization which always happens on a reboot.

Sometimes you can simply log out and log back in, and the requirement to reboot is nowhere nearly as frequent as it used to be, believe it or not, but yes you still have to reboot for kernel patches and core service updates, and there are a lot of those things these days.

> Windows won't let you delete a file that's still in use, so this scenario can't happen.

Windows lets you delete files which are open all you want, and Windows also lets the application which opens the file prevent that. A lot of things like this are blamed on Windows when it's actually Windows providing options to the application developer, and the application developer choosing to take advantage of options like that when they don't need to.

see: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/n... and note in the left side nav that reading, writing, and locking are all separate operations.

(This is a common misconception that I wanted to clear up, and isn't super relevant to the topic at hand.)

You can also use the debugger on any system where the debugger can attach to a process and make it call system calls.

I have done something similar to recover data that was still available in a process but no longer in any file - an overwritten configuration file.

Be careful though - one mistake and you can crash the process, losing the file!

This includes executables. I've had Tmux incompatibly upgrade itself on my while I was running an important job; I recovered the old executable from the running Tmux server, then used it connect and finish up the job.

Reply on news.ycombinator.com