Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #25227
| Path | csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail |
|---|---|
| Return-Path | <gandalf@shopzeus.com> |
| X-Original-To | python-list@python.org |
| Delivered-To | python-list@mail.python.org |
| X-Spam-Status | OK 0.041 |
| X-Spam-Evidence | '*H*': 0.92; '*S*': 0.00; 'removes': 0.05; 'file)': 0.07; 'rename': 0.07; 'subject:file': 0.07; 'wrapped': 0.07; 'subject:How': 0.09; 'deletes': 0.09; 'descriptor,': 0.16; 'missing?': 0.16; 'posix': 0.16; '(in': 0.18; 'followed': 0.20; 'file.': 0.20; 'error.': 0.21; 'sorry,': 0.22; 'references': 0.23; 'to:2**1': 0.23; 'second': 0.24; 'header:In-Reply-To:1': 0.25; 'header:User-Agent:1': 0.26; 'disk': 0.27; 'points': 0.29; 'this.': 0.29; 'file': 0.32; 'to:addr:python-list': 0.33; 'received:192.168.0': 0.35; 'there': 0.35; 'explain': 0.36; 'but': 0.36; 'operating': 0.36; 'possible': 0.37; 'subject:: ': 0.38; 'system.': 0.39; 'to:addr:python.org': 0.39; 'received:192': 0.39; 'received:192.168': 0.40; 'help': 0.40; 'first': 0.61; 'received:62': 0.62; 'wide': 0.62; 'different': 0.63; 'more': 0.63; 'soon': 0.70; '#1:': 0.84; 'received:192.168.0.101': 0.84; 'received:192.168.13': 0.84; 'received:62.179': 0.84; 'received:62.179.121': 0.84; 'received:upcmail.net': 0.84; 'step,': 0.84; 'subject:status': 0.84 |
| X-SourceIP | 89.134.225.226 |
| Date | Thu, 12 Jul 2012 19:38:37 +0200 |
| From | Laszlo Nagy <gandalf@shopzeus.com> |
| User-Agent | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 |
| MIME-Version | 1.0 |
| To | Christian Heimes <lists@cheimes.de>, python-list@python.org |
| Subject | Re: How to safely maintain a status file |
| References | <CAOV1wRVtm27yWez1HZuN8=ia-TyM2aXp9QCUbSZ5aZExP_ZChA@mail.gmail.com> <sanjv7lo0vb3rlhip4ov1gpgp4gs51bvfr@invalid.netcom.com> <4FF9F454.40207@shopzeus.com> <jtcvf8$ock$1@dough.gmane.org> <4FFEC371.5040703@shopzeus.com> <4FFECB96.9040601@cheimes.de> |
| In-Reply-To | <4FFECB96.9040601@cheimes.de> |
| Content-Type | text/plain; charset=ISO-8859-1; format=flowed |
| Content-Transfer-Encoding | 7bit |
| X-BeenThere | python-list@python.org |
| X-Mailman-Version | 2.1.12 |
| Precedence | list |
| List-Id | General discussion list for the Python programming language <python-list.python.org> |
| List-Unsubscribe | <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe> |
| List-Archive | <http://mail.python.org/pipermail/python-list> |
| List-Post | <mailto:python-list@python.org> |
| List-Help | <mailto:python-list-request@python.org?subject=help> |
| List-Subscribe | <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.2051.1342114916.4697.python-list@python.org> (permalink) |
| Lines | 32 |
| NNTP-Posting-Host | 2001:888:2000:d::a6 |
| X-Trace | 1342114916 news.xs4all.nl 6886 [2001:888:2000:d::a6]:44601 |
| X-Complaints-To | abuse@xs4all.nl |
| Xref | csiph.com comp.lang.python:25227 |
Show key headers only | View raw
> Sorry, but you are wrong. It's just one operation that boils down to > "point name to a different inode". After the rename op the file name > either points to a different inode or still to the old name in case of > an error. The OS guarantees that all processes either see the first or > second state (in other words: atomic). > > POSIX has no operation that actually deletes a file. It just has an > unlink() syscall that removes an associated name from an inode. As soon > as an inode has no names and is not references by a file descriptor, the > file content and inode is removed by the operating system. rename() is > more like a link() followed by an unlink() wrapped in a system wide > global lock. Then please help me understand this. "Good" case: process #1: unlink(old status file) process #1: rename(new status file) process#2: open(new status file) process#2: read(new status file) "Bad" case: process #1: unlink(old status file) process#2: open(???) -- there is no file on disk here, this system call returns with an error! process #1: rename(new status file) If it would be possible to rename + unlink in one step, then it would be okay. Can you please explain what am I missing?
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: How to safely maintain a status file Laszlo Nagy <gandalf@shopzeus.com> - 2012-07-12 19:38 +0200
csiph-web