[Samba] Real-time file synchronisation

[Mike Fedyk]

Simon Hobson wrote:

> Chris Ricks wrote:
>
>>>  And what does the vendor propose to do about the problem of changing
>>>  a binary whilst it is in use ? Having said that, I have done in-place
>>>  upgrades on Unix systems by MOVING the original file and slipping the
>>>  new one into place - if it's in use then the system will continue to
>>>  use the old file (referenced by inode no, not file name) until it is
>>>  closed.
>>
>>
>> An excellent point. They often do such things whilst people are 
>> working. If
>> I recall correctly, Windows' VM model does not horde executable data 
>> in swap
>> space (which is why compressed executables stay compressed or 
>> something -
>> I'd have to look at UPX's docs). Considering it's Windows, I don't 
>> like the
>> idea of trying to move such things around, even if Windows should lock
>> running executables.
>>
>>
>> Further, do you know offhand if the trick you use above carries 
>> across the
>> UNIX-Windows divide that Samba takes care of? I know that Samba will 
>> use FDs
>> to reference things, but SMB is a complicated protocol...
>
>
> In principal, but I know Samba has it's own locking mechanism and I 
> don't know if that works by file name or file id - hopefully one of 
> the people with knowledge of the internal could answer that one.
>
> As long as the Samba locking uses inodes and not filenames, then I see 
> no reason it shouldn't work. 

I don't know the exact semantics, but samba allows you to change shares 
by modifying the config file and sending a HUP signal to the smbd 
processes -- or just waiting for it to check the config files during 
operation.

My idea is to run an access file from a samba server.  The data is kept 
on a sql server, so just reports and forms will be in the access file.

 o have tow directories share-a and share-b
 o smb.conf points to share-a
 o change the files in share-b
 o change the smb.conf file to point to share-b

I know that at least on logout the user will get the update, and IIRC 
when all files are unlocked on the server, or for that share.

Can someone comment on whether this is a implementation quirk that 
should not be depended upon on the 3.0.x samba series?

Thanks,

Mike