On 10/05/2011 16:14, Gerhard Fiedler wrote:
> A file that is in the process of being written (that is, open for
> writing by another process) can't reliably be copied for later use --
> that's a simple fact. You can copy what's currently there, but there is
> no guarantee that what's there is useful and won't crash the app that
> uses it next time. You only have a guarantee that the file contains
> useful data if you communicate with the app and the app makes sure that
> it finishes all writes that are part of an (conceptually) atomic write.
> This is not an Explorer problem, and I expect that any file manager I
> consider as replacement would work similarly in this respect.
>

All very true. Backups are best done with all applications closed :)
>> >  Thanks in advance for suggestions, and your recommendations for
>> >  explorer replacements that you really like. I find there are too many
>> >  to choose from, so hope an experienced user has some recommendations.
> Every now and then I look at replacements, but so far I found that the
> downsides make it not worth it. One of the downsides is that many
> programs create interfaces within Explorer, and if the replacement
> doesn't replicate all this (or at least all that's important to me),
> this can reduce the usability quite a bit for me.


any standard Shell GUI may be unsafe or unstable for large copies (other=20
than a real backup program, and there is one included in windows:

Start | run | ntbackup

However in many cases xcopy with suitable options is very powerful and=20
can skip files already copied but unchanged and not over-write newer=20
destination files. It will on occasion copy "open" files that Explorer=20
will not (which sometimes are not being modified but used as "virtual=20
memory" or being read by Media Player etc)

It can be used in an AT scheduled .cmd script (more commands than .bat=20
scripts?)
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.