Charles Dye wrote:
| ---Quote (Originally by Roedy)---
|| If I write code like this:
|| copy /s G:\bks\*.* V:\bks\
|| where V: is an empty DVD,
|| how are the DESCRIPT.ION files handled? Do they get copied over and
|| over once per file, each time made larger, or is 4NT copy clever and
|| composes them in a scratch area or in RAM and only writes them once
|| at the end?
| I believe it's opened, written and closed multiple times. If that's
| a problem, you can just turn off description processing with SETDOS
| /D0 and either copy the existing DESCRIPT.IONs, or else create your
| own by e.g. redirecting from a TEXT / ENDTEXT block or a here-doc
| block, or building them in the %TEMP directory and moving them over
| when finished....
Since all files are to be copied from the source, the existing DESCRIPT.ION
files are exactly what need to be copied, without any manipulation (unless
there are hidden files with descriptions in the source, which are not to be
copied). For this reason I think the most efficient way is to disable
description processing using SETDOS /D0, and to include copying the existing
DESCRIPT.ION files by either of 3 methods: 1/ by unhiding them first, or 2/
by specifying that hidden files are also to be copied, or 3/ by explicitly
copying them. Which of the three methods is best depends on the
circumstances. Only if there are descriptions of hidden files in the source,
and those hidden files are not copied, is there a need for any manipulation
at all. In such event the simplest procedure may be to copy twice - first to
a buffer area on a local hard disk, allowing incremental creation of new
DESCRIPT.ION files, then copying all files, including hidden files from the
buffer area to the target, after turning off description processing. This
method is worth doing only if the target itself is not a local hard disk,
but a (much) slower device (e.g., CD-R).
If the target is a local hard drive, dynamic buffering both by the file
system and often by the target disk drive the delays associated with
incrementally building the description files may not be worth worrying, esp.
if a large number of small files is copied. A few large files are similarly
not overly time consuming, because the DESCRIPT.ION files are not
manipulated too often. Only if there is a mix of very large files, whose
delivery purges the caches of DESCRIPT.ION file data, and small files with
descriptions are interspersed would I expect significant speed degradation
due to description processing.