As the modified subject line says, what follows is pure technobabble...

On 9/24/2015 7:56 AM, wrote:
On Thu, 24 Sep 2015 04:34:32 -0400, look wrote:

On 09/24/2015 02:16 AM, wrote:
One of the down sides of W/7 for me is it will not talk to the W/98
machine.
In XP it is seamless.

It can be done but is a bit tricky.
Google "windows 7 to windows 98 networking" (without the quotes)


The best solution for me though was to buy my own network storage device.

http://www.amazon.com/Cloud-WDBCTL00.../dp/B00EVVGAFI

That might be a good solution for net storage but it won't do much for
my scanner ;-)

I have a mirrored pair on one of my machines that maintains my common
files. I had one of those "toasters" but it was far from trouble free.
To start with it required a driver on every machine that used it and
that was bugware.

I've given up on COTS NAS boxen. They all tend to be "closed" solutions
(even those built on FOSS software). A good test is to crash a volume
(after having made an offline backup!) and see how painful and successful
recovering the volume will be! Then, crash the *appliance* (i.e., imagine
the *box* has died) and trying to recover the volume contents on "something
else". So, *when* either of these scenarios manifest, you'll know
what sort of nightmare you'll encounter! (Hint: rebuilding a multi-TB
array can be frighteningly slow -- especially on the underpowered
hardware often used for these appliances!)

Instead, I've been designing a "distributed NAS/RAID" system. I use a
set of Optiplex FX160's:
http://gallery.techarena.in/data/513/Dell_FX160_1.JPG
running headless and diskless. External (portable!) USB drives act as the
persistent stores. I PXE boot a custom OS/userland that turns them into
appliances.

This allows me to serve files via a wide number of protocols: SMB/CIFS,
NFS, FTP, HTTP, etc. So, the stores are just seen as bytes -- they
don't care if they are accessed from a DOS machine, Windows, OS/X,
UN*X, etc.

Daemons running on the boxes (more than one box could be online at any
given time, obviously) catalog the contents of the attached volumes.
Filename, "container" (which may be a directory *or* the name of an
archive "file" -- or, even an archive within an archive!), size,
MD5 fingerprint, date of modification, etc. are cataloged and maintained
on an RDBMS.

From this, the system can (automatically) determine equivalences; file
X on volume Y in container Z is another instance of file A on volume
B in container C.

A daemon periodically walks through the filesystem verifying each file
is accessible and HAS NOT BEEN CORRUPTED (i.e., it's computed MD5/size
agrees with its *stored* MD5/size). So, a user knows that a file is
still present (RDBMS catalogs the names of existing files; if a file
has gone missing, it will exist in the RDBMS but not on the associated
volume in the specified container!). AND, knows that it's contents are
still intact -- even if he hasn't tried to access the file recently!
(the daemon has done so for him!).

The equivalence relationships allow the system to recover a lost file
though this may require human intervention (e.g., if the backup copy
exists on another volume attached to a different host that isn't currently
powered up, then the user must perform those steps!).

It's not designed to be a highly *performant* solution but, rather,
automate what a user would do in an ad hoc manner to preserve large
quantities of information without having to herd them into a
single appliance:
"Crap! My copy of RinTinTin is trashed! Where do I have *a*
backup squirreled away? Let me drag out that disk and find
the backup. Then, refresh my "original" while I am at it
to ensure that I have at least N copies to fall back on!"