Hi Simon,
My responses are interleaved with your questions.
Post by Chris Ricks-----Original Message-----
Sent: Friday, 1 October 2004 1:12 AM
Subject: Re: [Samba] Real-time file synchronisation
Post by Chris RicksHi all!
I'm looking for a method of doing the following, given that I'm taking
care
Post by Chris Ricksof a network with a Samba 3.0.6 box (running Mandrake 10.0) acting as a
PDC
Post by Chris Ricks. 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
Post by Chris Ricksserver 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
Post by Chris Rickschanges propagated out to clients as the share is updated without the
users
Post by Chris Ricksbeing made aware. Essentially, the software vendor is demanding that
everyone run their software from the network share as to ensure
consistency,
Post by Chris Ricksbut I hardly think a 300 MB application with 15 MB (!!) executables
(about 8
Post by Chris Ricksof 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! :-)
Post by Chris RicksHow 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.
Post by Chris RicksDo 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...
Post by Chris RicksDo 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.
Post by Chris RicksOne 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...
Post by Chris RicksSimon
--
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