Re: [coldsync-hackers] ColdSync 1.5.0 snapshot (and RFC)

[Andrew Arensburger <arensb+CShackers@ooblick.com>]

On Sun, 12 Nov 2000, John-David Smith wrote:
> Andrew Arensburger wrote:
> >         I guess I should point out that I tentatively deleted your install
> > mode, when I realized that it was essentially the same as restore mode.
> 
> I thought restore mode was to restore everything from a directory, as in the
> case of a hard reset.

	That's the way it was, originally. Now it's better, IMHO:

	coldsync -mr /my/file.pdb /my/dir

copies /my/file.pdb , and every database in /my/dir to the Palm. Since you
can specify individual files, you can use this to install files.

> My install mode was for when you've just downloaded a new
> program, and you want to install it directly, without doing any checking,
> conduit running, syncing, etc.  Or you want to install a version of a database
> with no processing etc.  This is equivalent to pilot-xfer -i.  Currently,
> coldsync takes much longer because of all the "User Info" it downloads in the
> first stage of any connection.  Any optimization here would be worth it.

	You're right.
	I just looked at the code to see why it was getting all the user
info and whatnot, and it has to do with the way I wrote the low-level
restore_file() function (see "src/restore.c"). That function assumes that
the list of databases on the Palm has been retrieved earlier, which is why
run_mode_Restore() fetches all the info.
	This is unnecessary. I'll fix it.

> > The list of files must be generated before any install conduits are
> > run. If you use the obvious implementation
> >         while (readdir() != NULL)
> > then you run the risk of running install conduits on databases that didn't
> > exist before. But not always, and inconsistency would be bad.
> > 
> 
> Even if readdir has the directory open it will be updated?  I think I tried that
> and it works fine (as I recall I used this exact test in ReadNextFile).  I'm not
> sure if this is guaranteed behavior, but I found it was not a problem.

	In a simple implementation, opendir() would simply open a
directory like any other file, and readdir() would read the next
entry. In such an implementation,
		while (readdir() != NULL)
			<something>
would catch files that were created during the execution of the loop.

	Under FreeBSD, opendir() appears to cache the entire directory,
but this isn't mentioned in the documentation. The Solaris 2.6
documentation says that readdir() may choose to cache directory
entries. Stevens[1] doesn't say anything about the matter. I suspect that
this behavior is implementation-dependent. Hence, for consistency, I think
it'd be better to cache the directory manually.

[1] Stevens, Richard W., "Advanced Programming in the Unix Environment."

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com			views of ooblick.com
	 Sign here: X_______________________________________


-- 
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.