On Sat, Jan 20, 2001 at 12:00:05PM -0500, Guido van Rossum wrote: > > Well, there is one more issue, which we can't fix terribly easy: test_fcntl > > tries to flock() the file. flock() doesn't work on all filesystems (like > > NFS) :P If we cared a lot, we could try several alternatives (current dir, > > /tmp, /var/tmp) in the specific case of flock, but personally I don't want to > > bother, and real sysadmins (who should care about the test failure) are > > more likely to build Python on a local disk than in their NFS-mounted > > homedirectory. At least that's how we do it :-) > These days, I would think that it's a pretty sure bet that the > system's tmp directory is not on NFS. Then we could just use > tempfile.mktemp() in that module, right? Or does the /tmp filesystem > on Linux (which AFAIK is a RAM disk implemented in virtual memory so > it uses swap space when it runs out of RAM) not support locking? Actually, most Linux distributions don't care enough about /tmp to make it a RAM-based filesystem. At least Debian and RedHat don't :) (There's a good reason for that: Linux's disk-data cache rocks if you have enough RAM, so there's no real gain in using a ramdisk) BSDI does (optionally) have such a /tmp, and probably the other BSD derived systems as well. But that doesn't mean it doesn't support locking, so that's not a real excuse. But like I said, I don't care enough to worry about it. I'll look at it before alpha2. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4