Hi, Niels.

NP>  > NP> If the program is as fast as you say, then what's the use :-)
NP>  > NP> It would only slow the program down.

NP>  > Yes, but I didn't know what you wanted - which you explain below.

NP>  I'm glad you understood my babble

It was quite clear, perhaps because I've been thinking so much about my
own similar requirements.

NP>  > NP> I have a program that does a CRC and stores it in the
time field of
NP> the
NP>  > NP> files directory entry, but this causes problems as well.

NP>  > Yes, I don't like fiddling with the time field, too much relies on
NP>  > knowing when files were created, like restores from backup.

NP>  Precisely!

NP> FM> FYI I'm trying to build something which I've wanted for a long time,
NP>     > to > report *any* changes to files (fuck the archive flag,
NP>     useless), to > maintain a complete catalogue of all my files (spread
NP>     across several > computers physically separated (by miles)), mirror
NP>     certain > directories > between those physically separate machines,

NP> Have you thought about leaving your home machine in a comms program that
NP> is running in Host mode and phoning home to transfer the work files to
NP> the home computer _before_ you leave work for the day?

Yes, I have thought about doing that. At the moment the work machine
doesn't have a modem, no other real need for one. I'll probably take the
old Netcomm 2400 in at some stage and do that.

NP> If this is an option then you can just call again when you reach work
NP> the next moening and retrieve the updated files.

Yeah. Would also solve the problem of running late and the ferry leaves
in 8 minutes and it takes 10 to copy to the floppies. :-)

NP> It also _guarantees_ an up to date "offsite" backup of what I would
NP> imagine would be very important files.

As you say. At the moment I have a copy at work, at home, on the
in-transit floppies and on the last night's archive tape at home.
Obviously not all equally current, but enough to recover from.

Your suggestion would also be helpful if say I stuff up something at
work/home, to just grab the previous one from home/work - now if I do
that I have to wait until the next day.

NP>  > This is very similar to what I need, except the machines are not
NP>  > networked. One is at work, the other at home and I need to keep a lot of
NP>  > stuff like my client etc databases in synch between the two. At the
NP>  > moment I just use a BAT file and PKZIP to put all the files in the
NP>  > relevant directories onto floppies (3) each morning and each night. I
NP>  > don't want to do just the changed files (by recognising and resetting
NP>  > the archive bit) in case for some reason I don't do the restore at the
NP>  > other end that day - I'd lose knowledge of the changes.

NP>  The above if an option would be a lot better.
NP>  Build a batch file to zip the required files up and then run a comms
NP>  program. Have a script to do the transfer to home and another script to
NP>  retrieve them in the morning. The batch file at home should unzip and
NP>  place the new files in the correct directories and then zip them up
NP>  again the next morning.  You could even have the batch file running as
NP>  a timed event.

I do currently use batch files for this, imaginatively named TOFLOP.BAT
and FROMFLOP.BAT. :-) The timed event is a bit of a problem because I
normally go to work at anywhere between 6:45 and 9am (and sometimes
later) so I prefer to run it manually after I've finished what I'm doing
at each location.

NP>  Either way your brain should be able to come up with something that
NP>  would save the hassle of the manual floppy work. You may wish to still
NP>  use the floppies as an iadded nsurance though.

Yeah, I'll do that at some stage although it's really only a small
hassle, 10 mins at each end of the day at each place. I won't bother
with the floppies when I have the dial-up capability.

NP>  > NP>  Looking inside the ZIPs is not a consideration for me.
Just so long
NP> as
NP>  > i
NP>  > NP> know that the contents of the zip have altered.

NP>  > It's not for me either for the straight mirroring exercise, but I want
NP>  > to build this thing into a total file catalogue of all my files anywhere
NP>  > - the work machine, my space on the work network drive, home machine(s),
NP>  > backup/archive tapes, etc.

NP>  You are looking at a more complete package than I was.  I have already
NP>  got ALL thr floppies cataloged using another program.

So have I (well, not quite all), but I want to have everything in one
place, and with features that I want that may not be in a 3rd-party
program.

NP>  > Twenty-four! How much space have you got?! I'm up to drive N: at the
NP>  > moment at home - A: & B: floppies, C: primary partition on the 2.1G
NP>  > drive, D: 212M drive, E: - M: secondary on the 2.1G, N: CD-ROM. But that
NP>  > will increase when I put the network in here.

NP> Remapping the drives to be accessible from all machines on a network is
NP> a fun exercise. :-)

Yeah, I'm looking forward to it! :-)

NP>  > NP> As far as the fast routines go, I will upload to TML with this
NP> message a
NP>  > NP> winprogram called DIGSIG.ZIP
NP>  > NP> It contains the complete description and formulas for 3 different
NP>  > methods o
NP>  > NP> generating a digital fingerprint of a file that you should find
NP>  > extremely
NP>  > NP> useful.

NP>  I will send it again, again in the hope that it actually makes it this
NP>  time.

Well, it got here! Thanks. For me the most useful part will be the
description of the message digest algorithms in the help file although I
don't think I need anything better than 32-bit CRC for this application.

NP>  > Yep, my routines allow specifiable extensions or "all files".

NP>  Good

NP>  > NP> 2.
NP>  > NP> Have the program take command line parameters of...
NP>  > NP> Drive to scan      (1 to 10 bytes)
NP>  > NP> Drive and directory where the applicable LST, DAT &
LOG files exist.
NP>  > NP> Name of DAT file to use.
NP>  > NP> Name of LOG file to use.

NP>  > Will be a simple main program wrapper calling my routines.

NP>  I want to be able to call your EXE from varying batch files and feed
NP>  the correct paramaters in depending on cirumstances.

Yep, that's how I'll set it up.

NP> [ BIG CHOMP]

NP>  > Wrapper.

NP>  > NP> 7.
NP>  > NP> When there is a CRC or filesize difference the program
should halt,
NP>  > display
NP>  > NP> on screen the full path and filename, the old and new sizes / the
NP> old
NP>  > and
NP>  > NP> new CRC's and request a reply as to whether the NEW size or CRC
NP> should
NP>  > be
NP>  > NP> written to the DAT file or to allow the old data to remain.
NP>  > NP> A simple "Update the DAT file with the new data ?
Y/N " should
NP> suffice.
NP>  > NP> (It should NOT halt simply because of a new file existing on the
NP> drive)

NP>  > Halt, or write/append to a log/error file? You might want to run this
NP>  > unattended.

NP>  Unattended yes, but halt when the above circumstances occur so that a
NP>  decision can be made, and followed through on at the time. Log it
NP>  anyway but maybe make the EXE with a parameter switch for stop or
NP>  nostop?

That's probably the best idea, so you can either run it unattended and
review the log file, or attended and fix the problem immediately.

NP>  > NP> 8.
NP>  > NP> Indication on screen as to which drive is being scanned
and some sor
NP> of
NP>  > NP> indication of what position the process is in towards completion.

NP>  > Hmmm.

NP>  You sound iffy about that one.  I need to be able to see where in the
NP>  process it is, so that I can estimate when to return to it.
NP>  My method knew at the satart how many files there were and would
NP>  display  ??? of 2400 files  ??%

Iffy only in how to implement. How does your method know at the start
how many files? I suppose I could scan the disk not doing the CRC, that
doesn't take very long, then do it again and do the calc. And then I
could give a better indication than number of files, show progress in
bytes as well.

NP>  > NP> The above is what I am already doing with my EXE.
NP>  > NP> I have the DAT & LOG files stored as hidden/system
in the root
NP> directory
NP>  > of
NP>  > NP> the drive scanned, and I am using different named DAT
& LOG files on
NP> any
NP>  > NP> given drive depending on whether the scan is being performed on a
NP> local
NP>  > NP> drive or a networked drive. This is essential as the
Pathname to any
NP>  > file i
NP>  > NP> different when it is accessed across the LAN  (Even the LAN path
NP> name
NP>  > could
NP>  > NP> be different depending on which machine the scan is
initiated from)

NP>  > I'll have to think about/experiment with LAN implications.

NP>  With LANTASTIC you have the ability to assign the LAN DIR of a machine
NP>  to one drive letter which when logged will give you access to ALL
NP>  drives on that machine.  A very handy feature not available in some
NP>  networking software (so I am told)

I think it should be reasonably straightforward, I just have no
experience of LAN programming (yet).

NP>  > NP> For speed gain, and less HD head movement,(very
significant) I place
NP> the
NP>  > DA
NP>  > NP> & LOG files in a working directory on a RAMDRIVE
and copy them back
NP> to
NP>  > the
NP>  > NP> correct location on completion.

NP>  > NP> It is the _same_ BAT file on all machines and it is
aware of which
NP>  > machine
NP>  > NP> it is being called from. It will alter the Ram drive
letter and also
NP> the
NP>  > NP> parameters it feeds the EXE accordingly

NP>  > All my disks/partitions have a volume label and a zero-length file in
NP>  > the root directory to identify them - this one is SYSTEM.04C, for
NP>  > example.

NP>  That's what I used ;-)

Great minds... :-)

NP>  > NP> What else do you need apart from time to write it ????? :-)

NP>  > Er, nothing except that. :-)

NP>  :-)

NP>  > At the time you wrote this my routines would have provided very close to
NP>  > what you want, with a suitable simple calling program. Since then I've
NP>  > temporarily destroyed some of the logic while I work on some of the more
NP>  > esoteric things which you aren't interested in. The ability to specify a
NP>  > starting "directory" which may not be a real
directory but say an
NP>  > archive file within a directory within another archive file etc etc for
NP>  > example has been quite a complex exercise. Which I've nearly completed.
NP>  > Then I'll put the other logic back and have a look at your requirements
NP>  > again.

NP>  Thanks heaps

Well yesterday I completed the testing of starting within an archive,
and calculating the CRC of *all* the files including within archives,
nested archives within archives, nested nested archives, etc. Ran it on
the C: drive, a bit over 20 mins for 390Meg. But the C: drive only has
about 240Meg of "real" files, so that included the time to unarchive
about 150Meg so I could calculate the CRC of the embedded files.

Regards, fIM.

 * * I'm really sorry about always saying I'm really sorry.
@EOT:

---