[Asterisk-Users] Outgoing spool file ignored

[tim panton]

On 17 May 2005, at 10:44, Peter Svensson wrote:

> On Tue, 17 May 2005, tim panton wrote:
>
>
>> The 'if possible' thing relates to filesystem design.
>> Almost all of the native UNIX filesystems support mv as an atomic  
>> action
>> - but only within the same filesystem.
>> (Imagine you create the file on one physical disk then 'move' it
>> onto a different disk - the kernel has no option but to
>> copy the file).
>>
>
> A Posix-compliant filesystem has to perform moves as an atomic  
> operation.
> The removal of the old file name and the creation of the new file name
> will from the point of view of any process be simultaneous. Also,  
> if the
> destination file name exists that name will refer either to the old  
> file
> or the new, there is no window where neither file or an incomplete  
> file is
> visible to a process.

Yep, that's what the spec says :-)

>
> Moves are not defined across mount points. The kernel will never  
> actually
> copy the file when move is calld. That is implemented in use space  
> by e.g.
> "mv" in fileustils etc.

Yes, sorry, I wasn't clear there - what I was trying to say was that
in this case it wouldn't be done as an atomic kernel action, but it came
out garbled.

>
>
>> So create your file in a temp directory on the _same_ file system as
>> the destination, then do the move.
>>
>> If your filesystem is remote (samba or nfs) or non unix native (FAT)
>> then it just won't work.
>>
>
> Nfs is a posix filesystem -> moves withing a device are guaranteed  
> to be
> atomic. I think is is defined for smb as well, though there may be
> restrictions and the atomicity may not be guaranteed.

Here we disagree. I had my fingers _badly_ burnt on exactly this one
some years ago.
I assumed that nfs being a posix filesystem would mean that atomic
actions would actually be atomic. That wasn't how it turned out.

In theory they are - but numerous bugs and 'optimizations'  in
various nfs implementations mean that I (personally) would
never depend on it again. Especially not if there are
multiple clients mounting the same filesystem read-write.

Tim.