为什么在UNIX中删除后可以访问文件？ [英] Why file is accessible after deleting in unix?

问题描述

我想过一个并发问题（Solaris中的 ），如果在阅读某人时试图删除同一个文件，会发生什么情况。我有一个关于 Solaris / Linux 中的文件存在的查询。假设我有一个文件test.txt，我在vi编辑器中打开它，然后打开一个重复的会话并删除该文件，但即使删除该文件我能够读取该文件。所以这里是我的问题：

• 在阅读时，我是否需要考虑任何锁定所以没有人能够在阅读时删除相同的文件。
  

• 什么原因显示不同的行为从Windows（如在Windows中，如果文件打开在一些编辑器比我们无法删除该文件）



• 删除该文件后，如果我还没有关闭vi编辑器的文件，我仍然可以读取该文件。

我一般会问文件，但是是平台特定的，例如 unix 。如果我正在使用一个Java程序（缓冲区读取器）读取文件和文件被删除，而读取时会发生什么，缓冲区读取器仍然能够读取下一个块或文件？

解决方案

你基本上有2或3个不相关的问题。文本编辑器喜欢在编辑会话开始时将整个文件读入内存。试想一下，你输入的每一个字符都被立即保存到磁盘上，其后的所有字符都被重写了一个地方以腾出空间。那太糟糕了。更好的是，你实际上正在编辑的东西是文件的内存表示（指向行的指针数组，可能附带有一些元数据），只有当你明确地保存时才会被转换回线性数据流。

任何相对较新版本的vim都会通知您，如果您正在编辑的文件是从原始位置删除的，则会显示消息

  E211：Filefilename不再可用
  

这个警告不只是为unix。 Windows上的gvim会给你，如果你删除正在编辑的文件。它提醒您，如果您不想让文件消失，您需要在退出之前保存正在使用的版本。

（注意：这个警告不会立即出现 - vim只是在把它移回前台时才检查原始文件的存在。）

这就是问题1，文本编辑器的行为 - 他们没有理由让整个会话保持打开状态，因为除了启动和保存操作之外，实际上并没有使用它。

问题2，为什么一些Windows编辑保持文件打开并锁定 - 我不知道，Windows的人都是疯子。

问题3其中一个实际上是关于unix的，为什么打开的文件在被删除后仍然可以访问 - 这是最有趣的一个。答案，保证当直接提交时震惊你：

没有命令，函数，系统调用或任何其他实际上请求删除文件的方法。

根据 rm 以及任何其他可能会删除文件的命令，系统调用取消关联。它被称为 unlink ，而不是删除或 deletefile 或任何东西相似，因为它不会删除文件。它删除一个目录中的文件和名称之间的关联的链接（a.k.a.目录条目）。 （注意：ANSI C添加了 remove 作为一个更通用的函数来安抚非unix人员，他们不打算实现unix文件系统语义，但在unix上，删除只是一个 rmdir ，如果目标是一个目录，并且 unlink ）

一个文件可以有多个链接（参见 ln 命令，了解它们是如何创建的）意味着相同的文件被多个名称所知。如果你 rm 其中之一，其他人就会停留，文件不会被删除。当你删除最后一个链接会发生什么？那么，现在你有一个没有名字的文件。但名称只是对文件的一种引用。至少有2个其他文件描述符和mmap区域。当一个文件的最后一个引用消失的时候，这就是文件被删除的时间。

由于引用有多种形式，可能导致文件被删除的事件。这里有一些例子：

• 取消链接（rm等）
  
• 关闭文件描述符
  
  
  
  • dup2（可以隐式地关闭文件描述符，然后用另一个文件描述符的副本替换）
    
  • exec（可以使文件描述符通过close-on-exec标志关闭）
    $ b $ limap munmap（unmap memory region）
    $ ul
    
  • mmap（如果您在已经映射的地址上创建新的内存映射，则旧映射不会映射）
    
    
  • 处理死亡（关闭所有文件描述符并取消映射进程的所有内存映射）
    
    
    
    • 正常退出
    
    
    • 内核产生的致命信号（^ C，段错误）
    
    
    • 从另一个进程发送的致命信号（kill）
      
    
    
  
  
  

  我不会称之为完整的列表。我不鼓励任何人尝试建立一个完整的清单。只要知道 rm 是删除名称，而不是删除文件，并且文件一旦没有被使用就立即消失。

  
  
  

  如果要立即销毁文件的内容，请将其截断。所有已经使用它的进程都会发现它的大小突然变为0.（这是对正常的文件访问方法的破坏，为了彻底销毁它，以至于即使有原始磁盘访问的人也无法读取曾经使用过的文件在那里，你需要覆盖它，有一个名为 shred 的工具。）

  
  

  I thought about a concurrency issue (in Solaris), what happen if while reading someone tries to delete the same file. I have a query regarding file existence in the Solaris/Linux. suppose I have a file test.txt, I have open it in vi editor, and then I have open a duplicate session and remove that file, but even after deleting that file I am able to read that file. so here are my questions:

  • Do I need to thinks about any locking mechanism while reading, so no one able to delete same file while reading.

  • What is the reason of showing different behavior from windows(like in windows if file is open in in some editor than we can not delete that file)

  • After removing that file, how I am still able to read that file, if I haven't closed file from vi editor.

  I am asking files in general,but yes platform specific i.e. unix. what will happen if I am using a java program (buffer reader) for read file and file is deleted while reading, does buffer reader still able to read the file for next chunk or not?

  解决方案

  You have basically 2 or 3 unrelated questions there. Text editors like to read the whole file into memory at the start of the editing session. Imagine every character you type being saved to disk immediately, with all characters after it in the file being rewritten one place further along to make room. That would be awful. Much better that the thing you're actually editing is a memory representation of the file (array of pointers to lines, probably with some metadata attached) which only gets converted back into a linear stream when you explicitly save.

  Any relatively recent version of vim will notify you if the file you are editing is deleted from its original location with the message

  E211: File "filename" no longer available
  

  This warning is not just for unix. gvim on Windows will give it to you if you delete the file being edited. It serves as a reminder that you need to save the version you're working on before you exit, if you don't want the file to be gone.

  (Note: the warning doesn't appear instantly - vim only checks for the original file's existence when you bring it back into the foreground after having switched away from it.)

  So that's question 1, the behavior of text editors - there's no reason for them to keep the file open for the whole session because they aren't actually using it except at startup and during a save operation.

  Question 2, why do some Windows editors keep the file open and locked - I don't know, Windows people are nuts.

  Question 3, the one that's actually about unix, why do open files stay accessible after they're deleted - this is the most interesting one. The answer, guaranteed to shock you when presented directly:

  There is no command, function, syscall, or any other method which actually requests deletion of a file.

  Underlying rm and any other command that may appear to delete a file there is the system call unlink. And it's called unlink, not remove or deletefile or anything similar, because it doesn't remove a file. It removes a link (a.k.a. directory entry) which is an association between a file and a name in a directory. (Note: ANSI C added remove as a more generic function to appease non-unix people who had no intention of implementing unix filesystem semantics, but on unix, remove is just a rmdir if the target is a directory, and unlink for everything else.)

  A file can have multiple links (see the ln command for how they are created), which means that the same file is known by multiple names. If you rm one of them, the others stick around and the file is not deleted. What happens when you remove the last link? Well, now you have a file with no name. But names are only one kind of reference to a file. There are at least 2 others: file descriptors and mmap regions. When the last reference to a file goes away, that's when the file is deleted.

  Since references come in several forms, there are many kinds of events that can cause a file to be deleted. Here are some examples:

  • unlink (rm, etc.)
  • close file descriptor
    • dup2 (can implicitly closes a file descriptor before replacing it with a copy of a different file descriptor)
    • exec (can cause file descriptors to be closed via close-on-exec flag)
  • munmap (unmap memory region)
    • mmap (if you create a new memory map at an address that's already mapped, the old mapping is unmapped)
  • process death (which closes all file descriptors and unmaps all memory mappings of the process)
    • normal exit
    • fatal signal generated by the kernel (^C, segfault)
    • fatal signal sent from another process (kill)

  I won't call that a complete list. And I don't encourage anyone to try to build a complete list. Just know that rm is "remove name", not "remove file", and files go away as soon as they're not in use.

  If you want to destroy the contents of a file immediately, truncate it. All processes already using it will find that its size has suddenly become 0. (This is destruction as far as the normal file access methods are concerned. To destroy it more thoroughly so that even someone with raw disk access can't read what used to be there, you need to overwrite it. There's a tool called shred for that.)

  这篇关于为什么在UNIX中删除后可以访问文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！