我需要find谁使用python（posix / linux）locking文件。 目前我使用这种方法：
flk = struct.pack('hhqql', fcntl.F_WRLCK, 0, 0, 0, 0) flk = struct.unpack('hhqql', fcntl.fcntl(self.__file, fcntl.F_GETLK , flk)) if flk[0] == fcntl.F_UNLCK: # file is unlocked ... else: pid = flk[4] 这个解决scheme不是架构独立的。 传递给fcntl的结构包含off_t或pid_t等字段。 我不能对这些types的大小做出假设。
struct flock { ... short l_type; /* Type of lock: F_RDLCK, F_WRLCK, F_UNLCK */ short l_whence; /* How to interpret l_start: SEEK_SET, SEEK_CUR, SEEK_END */ off_t l_start; /* Starting offset for lock */ off_t l_len; /* Number of bytes to lock */ pid_t l_pid; /* PID of process blocking our lock (F_GETLK only) */ ... };
有没有其他的方法来findPID？ 或者可能是off_t和pid_t的大小？ 解决scheme必须在不同架构之间完全可移植 。
编辑我决定使用lsof程序，如下所示。 另一个select是parsing/ proc /locking文件。
也许你可以尝试使用外部程序lsof来做到这一点？
Lsof revision 4.85 lists on its standard output file information about files opened by processes for the following UNIX dialects: AIX 5.3 Apple Darwin 9 and Mac OS X 10.[56] FreeBSD 4.9 and 6.4 for x86-based systems FreeBSD 8.[02] and 9.0 for AMD64-based systems Linux 2.1.72 and above for x86-based systems Solaris 9, 10 and 11
我之前使用过'hhllh'因为我认为它会跨平台最接近off_t 。 但是最终我决定使用'hhqqh' ，它适用于32位和64位系统。
我对这个解决方案感到惊讶，但是我所看到的32位盒子似乎是bits/fcntl.h创建了flock结构，除非系统已经定义了__USE_FILE_OFFSET64 （在这种情况下，它只是使用常规'ol off_t ），所以它看起来像l_start和l_len的大小总是8（python结构格式l_len 'q' long long ）。
这可能不是完全可移植的，我不能说所有现代的32位系统都会这样做，但现在对我来说足够好了 – 所以我想我会提及它，以防其他人（比如我自己）必须执行另一个进程，并执行一堆字符串解析，YMMV。 此外，如果我误解（或不好解释）为什么这个格式字符串似乎在两个平台上工作 – 也许有人可以纠正我？