Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!transit4.readnews.com!panix!not-for-mail From: Grant Edwards Newsgroups: comp.lang.python Subject: Re: locking files on Linux Date: Thu, 18 Oct 2012 13:57:04 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 27 Message-ID: References: NNTP-Posting-Host: dsl.comtrol.com X-Trace: reader1.panix.com 1350568624 15268 64.122.56.22 (18 Oct 2012 13:57:04 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Thu, 18 Oct 2012 13:57:04 +0000 (UTC) User-Agent: slrn/pre1.0.0-18 (Linux) Xref: csiph.com comp.lang.python:31637 On 2012-10-18, andrea crotti wrote: > 2012/10/18 Grant Edwards : >> On 2012-10-18, andrea crotti wrote: >> >> File locks under Unix have historically been "advisory". That means >> that programs have to _choose_ to pay attention to them. Most >> programs do not. >> >> Linux does support mandatory locking, but it's rarely used and must be >> manually enabled at the filesystem level. It's probably worth noting >> that in the Linux kernel docs, the document on mandatory file locking >> begins with a section titled "Why you should avoid mandatory locking". > > Uhh I see thanks, I guess I'll use the good-old .lock file (even if > it might have some problems too). > > Anyway I'm only afraid that my same application could modify the > files, so maybe I can instruct it to check if the file is locked. If what you're guarding against is multiple instances of your application modifying the file, then either of the advisory file locking schemes or the separate lock file should work fine. -- Grant Edwards grant.b.edwards Yow! All this time I've at been VIEWING a RUSSIAN gmail.com MIDGET SODOMIZE a HOUSECAT!