No.
Probably too much info coming...
The Dropbox folder exists on each of my machines as well as the Dropbox
servers in the US. If I put a program in the DB folder then each machine
will have a copy of that file, but I don't have to copy it around all the
machines manually, it happens automatically.
If any/all machines are not connected to the internet the files still exist
on each machine. When each machine is next connected to the internet the DB
client software on each one works out what has changed on that machine since
it last talked to the DB servers and uploads change details (not the whole
files, just the bits that are different). It also downloads details of
changes that have happened on other machines I have so, after a while, all
the machines come back into sync.
For example, a while ago I installed FileZilla (an FTP client). I ran the
install on just one of my machines, but put the app into
C:\My Dropbox\Programs--ALL-\~open-source filezilla V3-7-3\
and subsequently set up a shortcut etc (also in a Dropbox folder so I only
had to do that once) to the FileZilla .exe.
[Not every app will work out of a 'shared' folder like that. I also have
some programs installed into machine-specific folders, eg:
C:\My Dropbox\Programs-<machine>\...
and you should realise that I therefore have 3 copies of eg the "SN130"
machine's folder, on the three machines. But because of the way that
shortcuts etc are setup, only machine X will ever use the contents of
machine-X's folder. You might think this is daft, but it means that I have
safety copies of SN130-specific folders on my other machines, as well as the
DB servers and when SN130 changes something in that folder, the changes are
synced to the server & other machines too.]
Filezilla has an fzdefaults.xml file which one can choose to place inside
its main app folder, and in that one can specify amongst other things:
<Setting name="Config Location">
$JN_DROPBXRT\Programs--ALL-\~open-source filezilla V3-7-3\config\
</Setting>
On each of my machines the environment variable JN_DROPBXRT contains the
machine-specific location of the dropbox folder. It is in fact at
C:\My Dropbox
on all of them, but needn't be. Anyway this part of the XML file tells
filezilla to read its config from the specified place - the \config
directory inside the app itself.
The Dropbox software syncs the whole thing so I end up with three copies of
the folder:
C:\My Dropbox\Programs--ALL-\~open-source filezilla V3-7-3\
on my three machines, all with the exact same contents. I installed it once
but all three machines have their own copy. If the install "in Dropbox" had
only put the app onto Dropbox's servers - then I would have a problem
because I'd only be able to run the app if I was online but that's not how
it works.
This way, I have a separate copy of the app on each machine. If I run
FileZilla on one machine that's offline (then I achieve nothing because FTP
is useless without a network connection) but suppose I start it anyway and
change some setting or other... Then the config files on that machine's
copy of FileZilla get changed. The previously identical copies on the other
two machines stay as they were until the changes made on this machine gets
copied to the others.
The other machines' copies of FileZilla will still work - they don't need to
know that one machine's FileZilla has got newer settings, yet. Eventually
(when all machines which have files different from their original values
have been online and compared notes with the Dropbox servers) the Dropbox
software will realise there are incompatible versions of the config files.
It either copies the newest set of configs to the other machines, bringing
them all uptodate, or (if those on the other machines have also changed
since the time when all n copies were last in sync) it places separate
copies of all versions on all machines. You have to notice this has
happened and decide for yourself which is the right file, but you can do
that from any machine because all of them have copies of all versions of the
file in question.
A drawback of DB is that their software doesn't alert you that conflicts
have happened (at least it didn't use to do so - I have a feeling there's a
way to get an RSS feed or something that might tell me. One certainly needs
to be aware of the risk and to manage it.
Duplicate copies of supposedly identical files are given names that show
that such and such a file is in conflict with another such. Every couple of
weeks I do a file search looking for such things - in my case I've found it
happens rarely, but I have been very careful how I've organised my files.
I also have some other strategies that look for instances of such files in
conflict with each other in places where I know through experience that
they're likely to happen - that's to say mainly in day-to-day notes files,
to-do lists etc. Typically it happens if I update a todo list on one
offline machine, then make a different change to the same todo list on
another offline machine. When those machines next send those changes to the
Dropbox server the server can't tell which change was "right". It does not
assume that the changes date-stamped earliest are the "right" ones, thank
goodness. It does save the original file (in its archives on the server)
and both copies of the two separate newer files. In essence one will retain
the original file name and the other will be renamed something like
<originalfilename>(XXXXX's conflicted copy <date> <time>).ext
where "XXXXX" is the name of the machine that created that copy of the file.
How do I detect these conflicts? Well it mainly happens to plain text files
that I manually edit... The text editor I use is programmable, and in
particular runs a program to set itself up every time I start to edit a new
file. I've put into that program a tiny bit of code that checks whether any
files with *conflicted* in their names exist in the same folder as any file
I happen to be about to edit. There's no perceptible delay in the startup of
an edit session (I timed it).
I have found the drawbacks are minor, and the advantages are great.
There are apps whose data I wouldn't put into DB, for example my news & mail
client. But that's really because it does an awful lot of file operations on
about 6500 separate files in hundreds of folders. I don't need nor want to
be able to run it on multiple machines at the same time, nor would it really
be safe to do so - it's not designed to support that. Instead I run it on
my main day-to-day machine. I keep daily zipped backups of the live app on
the day-to-day machine, and once every few days I make an unzipped copy of
the whole app into Dropbox. Because DB only uploads changes it doesn't have
to upload the whole size of those 6500 files when I do that, because a lot
of the data in the app hasn't changed. But DB does go a bit frantic while
it is checking what has changed and deciding what to upload. If I need to
run the mail & news client on a different machine I install the app there
and give it a copy of the most recent DB copy of the 6500 files.