当检查Linux下的/proc/<pid>/目录的“long”目录列表时，我注意到目录中的伪文件项有时与它们有不同的时间。
从我所知道的内部工作原理来看，结构中没有任何“任意”或“不可预测”的属性，一切都是确定性的，一切（包括文件时间）都必须根据某些标准来确定; 这个标准是否有用是重要的问题。
例如，目录本身（ /proc/<pid>/ ）上的时间戳似乎反映了相应进程的开始时间（进程ID，至less – 不会通过调用exec来更新），而各种条目如proc/<pid>/fd/或/proc/<pid>/cwd可能是不同的值。 我最好的猜测是，这些信息中的很多caching了第一次检索信息的时间，但很难说清楚。
这里有没有什么有用的知识？
您可能知道， /proc下的文件是内存中的文件，这意味着它们不存在于硬盘上。 但是，他们可以被视为任何其他文件。 我没有看到这些文件修改时间的任何特殊含义。 它们就像您的文件系统下的任何其他文件一样。
您可以尝试检查一个文件的时间，然后touch它。 如预期的那样，文件修改时间将被更新。
/proc只是另一个文件系统，其中的结束条目就像其他文件系统一样被创build。 如果您创build一个进程，则会创build/proc/<pid>/ entry来保存进程中的数据。 当这个进程打开一个文件描述符时，在/proc/<pid>/fd/创build一个条目。
至于有用的知识，我没有机会使用/proc/<pid>/的内容，但我希望有一天我可以。 这取决于很多对你有用的东西。 与安全专家相比，系统pipe理员会发现比数据库pipe理员更有趣的事情。 不过，知道有这样的数据是好的。 有一天它可能会得心应手，但我不会花太多时间来学习这个问题的细节。 那是因为对我个人而言，这将是糟糕的时间投资。 你的旅费可能会改变 ：）。
编辑 ：我无法适应我对tylerl的评论内的评论的反应，所以它在这里。
泰勒，你是对与否在同一时间，取决于如何看待问题（想想：光的波/粒子二重性）。 当你说procfs不是一个“真正的”文件系统时，你当然是对的。 您不能创build目录或文件，或在那里存储数据。 是的，这是一个允许访问某些内核结构的API，它绝对不会创build任何磁盘结构。 我不太确定内存结构（ /proc目录中的[cm]时间存储在哪里？），但是我承认无知并且不会争辩这一点。
另一方面，当你想探索procfs ，看看里面的东西，并从那里的条目中学习，你可以在很大程度上把它当作“只是另一个文件系统”。 你可以阅读一些“文件”，你可以写（通常是严格定义的值）到一些“文件”。 当你创build一个进程时（比如说运行bash & ），一个/proc/<pid>条目的创builddate将与创build进程的时间相对应。 我认为，对于“看看有什么”模型，一个足够好的近似是“在创build进程时在文件系统中创build该条目”。 当然，严格来说，这可能是一个谎言。 不过，如果你不需要倾倒在你身上的全部真相，这是一个非常有用的谎言。