Nп/п : 55 из 100
 От   : Charlie Gibbs                       2:5075/128        15 сен 23 18:14:53
 К    : Rich                                                  15 сен 23 21:16:02
 Тема : Re: Weird code crash
----------------------------------------------------------------------------------
                                                                                 
@MSGID: Lpcc.12241@fx42.iad>
3da97557
@REPLY: 1@dont-email.me> 18976005
@REPLYADDR Charlie Gibbs
<cgibbs@kltpzyxm.invalid>
@REPLYTO 2:5075/128 Charlie Gibbs
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: 1@dont-email.me>
<ygamsxoixhx.fsf@akutech.de> 4@dont-email.me> <ygail8biyxm.fsf@akutech.de>
1@dont-email.me> <ygaedizitb9.fsf@akutech.de> 2@dont-email.me>
<yga4jjvik9o.fsf@akutech.de> 1@dont-email.me> 1@dont-email.me>
@RFC-Message-ID:
Lpcc.12241@fx42.iad>
@TZUTC: 0000
@PID: slrn/1.0.3 (Linux)
@TID: FIDOGATE-5.12-ge4e8b94
On 2023-09-15, Rich <rich@example.invalid> wrote:

> The classic "lock free" solution to this one is for the writer to 
> create and write to a temporary file, and after closing the temp file 
> to rename() it to the name of the real file.  Rename is documented to 
> be atomic, so the reader would never see a half open, or partially 
> complete, file in this case.

I`ve always deleted the original file before doing the rename,
probably because under MS-DOS or Windows the rename will fail
if the original file already exists.

As a side note, don`t use this technique if you`re porting your
code to Windows, where the delete/rename paradigm is permanently
and incurably unreliable.  When you ask Windows to delete a file,
it queues the request and doesn`t actually delete the file until
it feels like it.  Sometimes this doesn`t happen until after
you`ve attempted the rename, which then fails because the original
file is still there.  Some time afterwards, Windows gets around
to doing the delete, and once your cleanup routine gets rid of
the work file, your data is gone for good.

This doesn`t happen very often, but even a 0.01% failure rate
can result in a trouble call every week or two if your program
is running daily at 1000 customer sites.

I discovered this little "feature" back in the Windows 95 days,
and as far as I know it`s still there.  The only safe workaround
is to copy the contents of the work file back to the original
file.  For small files the time difference is neglegible, and
for large files... well, too bad, so sad.  Suck it up and wait.
Or convince the customer to switch to Linux.

-- 
/~\\  Charlie Gibbs                  |  They offer a huge range of
\\ /  <cgibbs@kltpzyxm.invalid>      |  world-class vulnerabilities
 X   I`m really at ac.dekanfrus     |  that only Microsoft can provide.
/ \\  if you read it the right way.  |    -- druck <news@druck.org.uk>
--- slrn/1.0.3 (Linux)
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх