[softwarelist] Re: SyncDiscs again
- From: David Pilling <flist@xxxxxxxxxxxxxxxxxxx>
- To: davidpilling@xxxxxxxxxxxxx
- Date: Fri, 1 Dec 2006 12:22:08 +0000
In message <4e8e203c04chris@xxxxxxxxxxxxxxxxxxxxx>, Chris Johnson
<chris@xxxxxxxxxxxxxxxxxxxxx> writes
multitasking is this. However, if a file is modified *after* the
snapshot
I believe SyncDiscs works its way through files, copying as it goes. No
snapshot in other words. There is a worry about having enough memory to
hold a snapshot.
It would be useful to include checking for open files, which
currently seems to stop SyncDiscs in its tracks. There are still a
number of apps that keep files open all the time for various reasons.
Yes. However this illustrates a point about SyncDiscs it does not copy
every single file, if it sees an extra folder, it issues a copy command
for the entire folder without bothering to go through the contents.
Does SyncDiscs 'simply' issue a stream of *copy, *wipe, etc commands
once it has sorted out the time stamps of existing files,
non-existent files etc?
It issues *copy for copying and moving, but it use the FS Control SWI
for wiping things.
If you (or someone else) wants to take over SyncDiscs and improve it,
then we can come to an arrangement on the source code. Or you can have
just the source code for the synchronisation part. Or I'd be happy to go
over to using *wipe so that the whole thing can be easily used as a
tool.
Or you could have the source for SyncDiscs alone and chop out all the
wimp code, turning it into a command line tool, which could be used from
other programs.
The thing about source code is that SyncDiscs uses my own RISC OS
library so anyone working on it has to come to terms with that (self
documenting code and obscure logic - e.g. flex_alloc() returns an
os_error *).
It seems like all you have to do is issue commands to Filer Action if
you want multitasking, however I wonder why I didn't do that... it would
for example be better to wait for one copy operation to terminate before
starting the next. I wonder if you'd end up just coding your own
multitasking copy.
It's one of those things, working out how to synchronise files is not
very complicated, multitasking copying is not that complex, etc. etc. it
all adds up.
--
David Pilling
email: david@xxxxxxxxxxxxxxxxxxx
web: http://www.davidpilling.net
post: David Pilling P.O. Box 22 Thornton Cleveleys Blackpool. FY5 1LR UK
fax: +44(0)870-0520-941
- Follow-Ups:
- [softwarelist] Re: SyncDiscs again
- From: Martin Wuerthner
Other related posts:
- » [softwarelist] SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
- » [softwarelist] Re: SyncDiscs again
multitasking is this. However, if a file is modified *after* the snapshot
It would be useful to include checking for open files, which currently seems to stop SyncDiscs in its tracks. There are still a number of apps that keep files open all the time for various reasons.
Does SyncDiscs 'simply' issue a stream of *copy, *wipe, etc commands once it has sorted out the time stamps of existing files, non-existent files etc?
- [softwarelist] Re: SyncDiscs again
- From: Martin Wuerthner