<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>AceJohnny2</author><text>&amp;gt; &lt;i&gt;A neat trick here is that you can effectively still access the file (even restore it) if a process has the file open, through the &amp;#x2F;proc filesystem.&lt;/i&gt;&lt;p&gt;A technique used in the most extreme unix system recovery story I&amp;#x27;ve ever read, by Al Viro:&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;yarchive.net&amp;#x2F;comp&amp;#x2F;linux&amp;#x2F;extreme_system_recovery.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;yarchive.net&amp;#x2F;comp&amp;#x2F;linux&amp;#x2F;extreme_system_recovery.html&lt;/a&gt;&lt;p&gt;Wherein:&lt;p&gt;* system libraries are recovered from init still having them mapped&amp;#x2F;opened, as you describe&lt;p&gt;* basic system utilities like &amp;#x27;ln&amp;#x27; are recreated from their syscalls and writing the assembly&lt;p&gt;* ELF binaries are recreated by crafting their headers manually</text><parent_chain><item><author>andrewla</author><text>What I found most interesting from working on some FUSE filesystems (and from the git pseudo-filesystem) is that removing a file via unlink is not a file operation at all, but an operation on the parent directory.  The only way that the filesystem knows how to find a file (an inode) is by finding it in a directory listing (which is itself a filesystem object).&lt;p&gt;The name itself is the giveaway -- &amp;quot;unlink&amp;quot; because you&amp;#x27;re removing a hard link to a file.&lt;p&gt;Similarly, access permissions are also properties of the embedding in the directory, rather than the bits of the file itself.&lt;p&gt;This is a place where POSIX and Win32 diverge significantly -- in Win32, permissions and access happen at the file level, which is why Windows is testy about letting you delete a file that is in use, while POSIX doesn&amp;#x27;t care -- the process accessing the file, once the file is open, maintains a link to the inode, and all the file data is intact, just not findable in the directory where it was initially located.&lt;p&gt;A neat trick here is that you can effectively still access the file (even restore it) if a process has the file open, through the &amp;#x2F;proc filesystem.</text></item></parent_chain></comment><story><title>Unraveling rm: what happens when you run it?</title><url>https://blog.safia.rocks/post/173241985600/unraveling-rm-what-happens-when-you-run-it</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>jwilk</author><text>&amp;gt; access permissions are also properties of the embedding in the directory, rather than the bits of the file itself.&lt;p&gt;No, in POSIX they are properties of the file. You can use fchmod() and fchown() to change mode and ownership via an fd.&lt;p&gt;&amp;gt; A neat trick here is that you can effectively still access the file (even restore it) if a process has the file open, through the &amp;#x2F;proc filesystem.&lt;p&gt;Yes, you can access them; but I don&amp;#x27;t believe you can link them. (But I&amp;#x27;d love to proven wrong. A few years ago I actually needed to un-unlink a non-regular file that was still open.)</text><parent_chain><item><author>andrewla</author><text>What I found most interesting from working on some FUSE filesystems (and from the git pseudo-filesystem) is that removing a file via unlink is not a file operation at all, but an operation on the parent directory.  The only way that the filesystem knows how to find a file (an inode) is by finding it in a directory listing (which is itself a filesystem object).&lt;p&gt;The name itself is the giveaway -- &amp;quot;unlink&amp;quot; because you&amp;#x27;re removing a hard link to a file.&lt;p&gt;Similarly, access permissions are also properties of the embedding in the directory, rather than the bits of the file itself.&lt;p&gt;This is a place where POSIX and Win32 diverge significantly -- in Win32, permissions and access happen at the file level, which is why Windows is testy about letting you delete a file that is in use, while POSIX doesn&amp;#x27;t care -- the process accessing the file, once the file is open, maintains a link to the inode, and all the file data is intact, just not findable in the directory where it was initially located.&lt;p&gt;A neat trick here is that you can effectively still access the file (even restore it) if a process has the file open, through the &amp;#x2F;proc filesystem.</text></item></parent_chain></comment><story><title>Unraveling rm: what happens when you run it?</title><url>https://blog.safia.rocks/post/173241985600/unraveling-rm-what-happens-when-you-run-it</url></story>