[Samba] Real-time file synchronisation

[Chris Ricks]

Hi Simon,

My responses are interleaved with your questions.

> -----Original Message-----
> From: Simon Hobson [mailto:shobson-lists at colony.com]
> Sent: Friday, 1 October 2004 1:12 AM
> To: Chris Ricks; samba at lists.samba.org
> Subject: Re: [Samba] Real-time file synchronisation
> 
> Chris Ricks wrote:
> >Hi all!
> >
> >I'm looking for a method of doing the following, given that I'm taking
> care
> >of a network with a Samba 3.0.6 box (running Mandrake 10.0) acting as a
> PDC
> >for about 15 W2K boxes:
> >
> >. There is a share full of program files and data files on the Samba box
> >. These files are currently synchronized at logon - all movement is from
> the
> >server to the clients via a logon script using XCOPY /D
> >
> >I want to engineer a solution that would allow updates of the share to
> have
> >changes propagated out to clients as the share is updated without the
> users
> >being made aware. Essentially, the software vendor is demanding that
> >everyone run their software from the network share as to ensure
> consistency,
> >but I hardly think a 300 MB application with 15 MB (!!) executables
> (about 8
> >of them) is really suitable for being "deployed" in that fashion.
> >
> >All comments appreciated!
> 
> I would say that your vendor is being unreasonable, and that you are
> correct to want to run these locally.

Funny that - last time I checked, Windows doesn't actually fit with the idea
of thin-client style computing at all! :-)

> 
> A few questions to think about :
> 
> How often do you update the application ? If it's only every few
> months, then there's no problem.

"Updates" are done every now and then, but very rarely for binaries. Most
updates take the form of replacing report files (of the order of 100KB).
This sort of update happens every few months.

> 
> Do you ever do it while users are working ? Well you shouldn't be !
> 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...

> 
> Do you have (or do you ever expect to have, any remote workers ? If
> so then there is no way (even on Broadband/ADSL) that you want users
> sucking that sort of file size down the pipe.

We do have remote workers, and they run the app locally with only queries
and result sets traversing the wire. That said, rsync makes short work of
that problem for keeping remote installs in sync.

> 
> One way of dealing with the issue is to make all the users log out
> and back in again when you upgrade. Another might be to run a
> scheduled task that periodically does an XCOPY, but then you'll run
> into problems of the program crashing when you change the binary
> running (or more likely a file in use error).

I was thinking of using dnotify / FAM and a conditional script. Most of the
DLLs will never change, the same for the executables. How Gupta's products
handle .QRP files changing underfoot will be interesting...

> 
> Simon
> 
> --
> Simon Hobson MA MIEE, Technology Specialist
> Colony Gift Corporation Limited
> Lindal in Furness, Ulverston, Cumbria, LA12 0LD
> Tel 01229 461100, Fax 01229 461101
> 
> Registered in England No. 1499611
> Regd. Office : 100 New Bridge Street, London, EC4V 6JA.

Best regards,

Chris