Wednesday 11/28/12 7:25 am

WARNING WARNING WARNING DANGER DANGER DANGER

If you destroy your home your car your neighbors’ pets — IT WILL BE ENTIRELY YOUR FAULT. I did nothing I hope for nothing I am free....

Introduction

JCOPY attempts to copy files. It’s a dangerous job, but etc. The point was, actually, to copy files from my hard drive to one or more CDR disks, using the wonderful but probably-not-ready-for-primetime “DirectCD” Adaptec “packet-writing” (“drag ’n’ drop”) drivers.

To accomplish this, JCOPY

  1. Will stop and ask if you want to insert another media when it fails to copy a file. This crucial feature means you can copy things bigger than a single CDR — like my ridiculous hard drive, even just the personal data sections — without inevitable failure. To do this with Xcopy, which is what I tried first, traditionally the plan was to set all the archive bits, and use Xcopy with the /M option to just copy files with the archive bit set, and then when it failed, you could restart it with new media. Aside from the annoying archive-bit twiddling, that failed anyway because as I found-out

  2. JCOPY used to try and whack file or directory names that began with a dot by prefixing them with the DOTCRASHCHAR, which appears to be the letter Beta. If this wasn’t done, at least in my tests, Xcopy crashed the Adaptec directCD s/w when it tried to copy a file named “...3dots” (this filename reliably crashed Adaptec s/w i.e. Windows 98 using several copy strategies including DOS “copy”). A few related anomalies presented themselves. ... Bu that was Windows 98 and the Adaptec directCD driver, both of which have gone the way of the dodo so long ago it hurts to think about. ... So if you really want that behavior after Thursday, October 24, 2012, do “FixDotCrash=1” in the ini file, and may the Deity have mercy....

  3. In addition, various convenience / enragement features are provided.

(Note that if you inspect JCOPY log files in DOS, like I do constantly, this Beta character will show-up like a half block graphics character. But it looks OK in notepad etc.)

JCOPY uses command-line options, even in W98!; my general approach was, as opposed to the user-friendliness and consequent infuriating inflexibility of BackupExec et al, that JCOPY would be totally intractable, requiring elaborate file-editing and batch files to get it to do anything. I’m trying to be funny, but this is actually correct; easy-to-use backup systems often turn out to be easy-to-fail — unless you expend the necessary effort to figure out the details, and then they’re no longer EZ. That is, you must pay attention to produce reliable backups.... Anyway, I use JCOPY invoked from MSDOS batch files (inside W98 of course; JCOPY is a 32-bit W95 GUI program), which typically contain a line like “JCOPY /Itask.ini” where “task.ini” is an ASCII file specifying all the ridiculous and elaborate things I want to do. See OPTIONS for unseemly details.

Anyway it’s worked 2 or three times.... Bon appetit! (http://owenlabs.org)

Hang-Ups

Monday, June 22, 2009 3:10 pm. Try erasing jcopysize.ini, wherever it is. This one was really embarrassing; here I thought there was something wacko about my brand-new tiny adorable Asus laptop — it’s the 16gig flash flavor, and I was trying to install an additional 16gig SDHC into its handy SD port, and I had all kind of dark suspicions about the compression on drive c:, and the HCness of the new drive e:, and how maybe I hadn’t properly executed try/except/end mumbo-jumbo on an ini file read I was doing. ... But in the end, it was ’cause I had copied jcopy, of course, from another computer, and when the program started and demanded an explanation from the user for some error — why the prompt box was off the screen! And the ini file it was trying to read when it wouldn’t come-back — i.e., as I tested it with debug prompts there were position/sized by the stupid file! ... Once I figured-out what an idiot I was, I tried to fix it with sanesize() (q.v. in main.pas; also min size/heights on the forms), but deleting jcopysize.ini is always a good plan. ... You note how normally we go from smaller to larger screens but only in these end-times, are we devolving to cute tiny computers, so the screens are smaller and foolishly-remembered positions/sizes will be invisible!

Two Styles: Single-Source, Multiple-Source

A great source of confusion in JCOPY is that “JCOPY c:\elsecoms\hide g:\bongo” might copy the “hide” directory to the “bongo” directory. This is the “single-source” style. “JCOPY c:\elsecoms\hide g:\bongo /s” would also copy all the hide subdirectories. So if “hide” had a subdirectory “seek”, when you were finished, there’d be a “g:\bongo\seek”. Note that the destination “g:\bongo” need not exist.

However, if it’s “JCOPY @g:\bongo c:\elsecoms\hide” — note the “@” — then it is assumed that it will be copying multiple sources to a single destination, presumably listed in the “file” specified after the “@” sign, and according to an elaborate syntax described below somewhere. The most important point about this syntax is that the source directories are appended to the specified destination directory in various obscure ways.

Vague Excuses

It’s all so simple.... Options below are shown in the command-line form — something like “/xBingo” — and/or in its JCOPY.ini form like “bingo=”, where it should appear in the usual way below the main section “[JCOPY]” in JCOPY.INI. There is no orthogonality in these varieties. It is possible to change the section name with “/eNewSection” on the command-line; this supports including all kinds of complicated instructions in a single JCOPY.ini file (if you typo the section name, chances are it’ll just do nothing). I.e. in the following endless complexity, where alternate “/i” specifications are suggested, an alternate /e specification could be used instead.

Also note:

Environment Variables

At Fri 1/21/2005 version “rak” or later, DOS-style environment variables are supposed to be honored in all the string JCOPY input. That is, something like “f:\CH+|d” could be “%cdrw%:\CH+|d” and, if there’s an environment “cdrw” set to “f”, it’ll work the same. Of course, testing’s been a little dim. (I’ll try it when I need it.)

Overwrite Protection

JCOPY won’t copy over existing newer files unless “NewerOnly=0” appears in the ini file. There is no command-line equivalent. Under the default conditions, JCOPY will only overwrite a destination file when its date/time is less than the source file, or if the destination doesn’t exist. This makes JCOPY safer in general, and also usable for that dread day when one must restore one’s files from assorted CDRs zip disk diskettes etc., tending slightly to avoid obliterating most-recent copies of various files. “NewerComplaint=1” makes the program pause and ask if you want to stop when this happens. If “NewerLog=0” (default) then newer-only skips aren’t logged; otherwise they appear in the log.

On the other hand, “DifferentOnly=1” will change the “neweronly” behavior so that only files with different dates — older or newer — will be copied. This feature is included for unusual Klingon backup sessions (it came in handy once during a great windows copy session when XP/W98/Windows confusions screwed-up about 10% of the dates). Note that neweronly messages will be polluted by occasional appearance of “dif?” to signify that might be actually due to DifferentOnly. And of course setting “DifferentOnly=1” crushes “neweronly” option.

The JCOPY board of arbiters highly recommends trying this nonsense out very carefully with, say, diskette drive A: as the destination.

Invoking JCOPY with any option containing a question-mark is supposed to produce this help, and then exit.

So basic operation’s like “JCOPY sourcedir destination [ops]”. Option letters are case-insensitive. No individual file copy. “source=c:\gregor”, “destination=f:\xyz\”. Note that if source directory is “.”, then the current directory is substituted.

Options

JCOPY is nothing if not options. There are many many many options....

/crc. Do a “nocopy” crc on the current directory. Does the following options:logfile=nocopy+.jcp
crc=1
nocopy=1
FixDotCrash=0
notcdr=’ABCDEFGHIJKLMNOPQRSTUVWXZ’
recurse=1
source=’.’
destination=’f:\’

See the individual options.

/crc:c:\elsecoms uses that as source, instead of ’.’. And also store the logfile in that directory.

/iBingo.ini. Use Bingo.ini as the init file, instead of the default JCOPY.INI. Incidentally, JCOPY searches for JCOPY.INI or the file specified by “/i” first in the current directory, and then in the JCOPY program directory. Probably unless you specify a path. (Also remember that the /eSection option which specifies a different [section] as opposed to the default [JCOPY], can often be used instead of /i; i.e. all the different activities can be segregated in a single JCOPY.INI with different sections.)

Note that if you use a path with /i/ic:\elsecoms\bingo.ini — it will change to c:\elsecoms — unless you use a “+” sign, i.e. “/i+c:\elsecoms\bingo.ini”.

/x will ignore any default or specified inifile present — i.e., only using command-line options — avoiding amusing and unintended persistence of options when you’re trying to just use command-line options (not really recommended, but test etc.).

/h, copy hidden files from stupid iMini-on-the-net; “hidden=1”.

/s, do subdirectories; “recurse=1”.

/m or /a, only copy files with archive bit set (but don’t reset archive). “arconly=1”.

nocopy=1 (command-line “/t”; /t- reverses) during a copy causes JCOPY to do everything as if it were copying — but not copy. This seems totally useless and in fact disappeared some time before Wed 1/23/02 4:23 pm, but I reintroduced it to produce JCOPY CRC log files (see below for the CRC feature). The problem is that the packet-written CDs JCOPY produces with Adaptec and probably other drivers — why, they can’t be copied by the same stupid CD software! Amazing eh!? So I use the CD one-fell-swoop copy to create a copyable-CD, but then of course the CD software has no way to check it, hence this idiotic nocopy option. I set-up as if I were copying the directory set I just copied, create the CRC file, and then use that to check the CD. At least it did that once or twice today.

Test Options

nodata=1 would cause copies to occur, but the destination files would be of zero-length. This is useful for discovering what magic file names will crash the Adaptec DirectCD drivers when I was jcopying to CDRs; use it with ...

log=alog (or command-line “-Lalog”) should cause the specified file name to get a log of JCOPY activity. PGMDIRZEd and DATEIZEd. If the specified name beings with a colon “:”, then the colon will be removed and the file will be CWDIZEd in the old boring way. Every destination file path appears on a line, plus various other amusing information. The file is opened and closed every time it’s written to, so it might slow things down, but on the other hand makes a nice “catalog” of large backups, i.e. to find which CDR a particular file wound-up on, since I think the destination media faults are logged somehow. Of course so far I’ve only gotten up to two CDRs, so it’s not that big a deal. Note incidentally that if the log file specifies an existing file, log material will be appended to that file; this is an artifact of the opening/closing strategy above, and was introduced so that JCOPY wouldn’t go mad when it attempted to backup the log file — which it will accomplish successfully, but of course only the part that’s been written so far.

The default is “log=df~_+.jcp”. Use “log=” to defeat any logging.

If the specified log file contains any path information — “:” or “\” — then an earnest effort is made to avoid copying the specified log file anywhere. Otherwise jcopy often attempts to copy whatever log file it made to the destination. I.e., for backups and stuff.

The log feature was created when I was trying to find exactly when the Adaptec s/w crashed. The idea is you find the last name in the log file, and then the next file is the offender. Finding the next file: inspect the directory of the offending file, unsorted. Typical file viewers don’t even let you do that, but the command-line “DIR” command apparently does so by default, at least here in Windows 98 (if it hasn’t been configured by some environment variable; see “DIR /?”). Then, the file that didn’t copy is the one after the last logged file. If it is the last file, then it will be the first subdirectory or the first file in that subdirectory.

Normally the log file will include thoughtful 32-bit hex checksums of passing files. The format will be like “|f:\dir\dir\filename|6C337B43” with the |s forming delimiters. See the exciting verify option below for more about this feature. “crc=0” will omit these numbers.

Startfile=f:\xyz\bingo\badness.x. After I went through the tedious process described above (“log”) I’d sometimes want to start the process somewhere in the middle, and this option supports that. You have to get the exact right name or it won’t work, which can be tricky. JCOPY goes through all the motions, but doesn’t copy anything until it gets to a destination file which matches. As a way of making it go through the motions all the way to the end, specifying an illegal name like “none|such” will do it.

@ Files: Multiple Sources

If the source directory, either on the command-line or in the ini file, is specified with a leading “@” sign, then that file is treated with a special new entirely additional syntax which, nevertheless, overlaps to some extent the stuff above. CWDIZEd. I.e. like “JCOPY @upwards.ml”, JCOPY will examine upwards.ml for source, destination, and etc. specifications according to the following astonishing scheme:

;Semicolons are comments.
;Every non-comment line has to end
;with a “|” (vertical bar)
;followed by options.
default|sa
;Set default option to sa
;(subdirectories, only copy files
;with archive-bit set).
f:\060500ml_fl\root|d
;Specify destination root
f:\ml+fl\|d
;Specify DATEIZEd destination;
;“+” is automatically
;replaced with date code.
;source files directories/files
;will be appended to the destination
;directory.
c:\gregor|s
;Source, subdirectory option:
;Backup c:\gregor and
;the subdirectories.
c:\gregor|
;Source without any option;
;any default options (see
;“default|sa” above) are
;used.
c:\|a
;Just backup root files
;with archive attribute
;bit set. Overrides any
;default options.
c:\|as
;Backup root and all
;subdirectories, with archive
;att bit set.
c:\|s-
;Backup root directory, overriding
;default s option for just this
;source directory.
FullMilleniumBackup|k
;like ini file “dstkey”;
;if the file doesn’t exist
;in the root directory of the
;destination, then failure.
MilleniumDriveC|x
;Ini “srckey;” etc for source. Should
;appear before source spec.
@Bingo.ml
;Line starting with “@” means
;“chain” to another spec file like
;this one. Doesn’t return.

and then just back ’em all up, one after another — copying the source to specified destination + the source directory path.

Note that the @ file logic is different from the ini file logic; the directory specified with “source=” or on the command line are copied to the “destination=” directory; but the files in an @ file “|s” specification are copied to the most-recent “|d” destination PLUS the source file directory. I don’t know why it’s that way; but it is, and it seems good. (It’s probably that way so you can go “JCOPY /x sourcedir destinationdir” and what it looks like will happen....)

Note that the astonishing “k” and “x” options (available as “dstkey=” and “srckey=” in the ini file) are consumed when used, i.e. the plan is they only happen once for each specification, which is probably what one wants. The utility of such primitive checks became apparent some time ago when I accidentally backed-up my laptop through the network to my desktop’s C: drive instead of the zip drive I had intended.

Multiple-Source Appended to Destination Directory

As noted, the destination specified via the “|d” thinegy gets the source directories appended to it. Two nouveau options that affect this appending process are

network_directory_style=two (default) means that a network source (i.e., in a multiple-source @file) like “\\xp911\d\gregor” will be converted into a JCOPY destination like “f:\dst_spec\d\gregor\” — that is, the first UNC (Universal Network Convention) path element is discarded. “full” would produce “f:\dst_spec\xp911\d\gregor\”. But then again, see auto_dst_drive.

auto_dst_drive=UNC (default) means that (1.) UNC (“\\”) sources are treated according to the “network_directory_style” option (above), and (2.) non-network sources discard the drive specification when concocting the destination. “auto_dst_drive=1” (command-line “/d”) is the same as “UNC”, except that non-network sources include the drive as a directory element in concocting the destination: “f:\dst_spec\d\gregor\”. That is, “auto_dst_drive=1” makes the non-UNC “@” source act like the default UNC “@” source, kind-of. (Also known as the “rational” version; because, typically, if I’m backing-up a multiple-drive machine, I don’t want to overwrite same-named directory files from different drives.) Finally, “auto_dst_drive=0” defeats the drive inclusion for non-UNC and UNC @ sources and the strangely-confused network_directory_style: the source directories are just appended without any UNC/drive decoration.

And now, some useful cleanup-style JCOPY ini-file activites:

stopbak=1” will attempt to reset the archive bits in the source directory/directories. The idea is one would contrive a special “reset archive” INI file (“JCOPY /iSTOPBAK.INI”) containing “stopbak=1”, which would reference the same list used for full backup, say (“source=@full.ml”), but would process it by going through the whole thing and resetting all the archive bits. JCOPY never resets archive bits on its own; you must tell it to. Thus making it intrinsically safer than, as far as I know, all other windows backup systems.

But then again, JCOPY had no verify (but does now; see next). I routinely set the DOS verify option in the system autoexec.bat file (“verify on”), and like a fool I trusted in that. However I began to get nervous after numerous CDR bit-rot failures, so read=1” will read the destination spec, complaining about bad reads; again, it doesn’t verify. So, like the “stopbak” example above, you’d contrive a special INI file with “read=1” and probably just set to the root CDR drive i.e. “destination=f:\”, set “recurse=1”, and go “JCOPY /iREADCK.INI”, and JCOPY would proceed to go through every single file on f: and read every byte. Of course, every byte could be 0x55, but that’s show business. (You understand, DOS media has some inherent failure checks, so if the data has been corrupted, it should cause read failures; however, if for some reason JCOPY evilly chose to copy all 0x55s instead of the original data, that is sad.) Remember to set “recurse=1” to do the whole drive. Of course the destination/recurse specs can be set as desired for various arcane tasks.

JCOPY Verify

And then I got more nervous, hence the init file option verify=log0712001654” (CWDIZEd). JCOPY will attempt to read the specified file and check the files specified within it against their checksums. That is, to use this marvelous feature, (1.) do a “normal” (ha ha) JCOPY with “crc=1” (default, probably); then use the resulting log file in an init file verify spec, and verification will proceed apace. The lines of interest in the log file look like “|F:\x0712001654\DRIVEL~\EDIR|6C337B43” i.e. the complete path of the destination copied file delimited by |s — which I’m almost certain are illegal in file names, at least this week — followed by a 32-bit checksum. This CRC is supposed to be the same (and was in a few tests) as that of “CRC-M2 - Cyclic Redundancy Checker, Version 1.12, 01/02/90, rtk”, a DOS program found here and there (“CRC.COM” or “CRC113.ZIP” etc.), the work of Raymond T. Kaya, supplied with C source. Thank you, Mr. Kaya. ... If VerifyComplete=0” is present in the ini file, then CRC errors will be complained-about when they occur, instead of being saved-up until the end. Although actually, (almost) every verify error encountered so far has been in the nature of a complete failure: JCOPY more-or-less hangs-up, fails to repaint with blotches all over it, and the CDR spins and spins. Try and click the STOP button, and at least on several occasions I’ve managed to exit gracefully — but you can safely conclude your backup is totally fungado. // Mon 12/02/02 7:38 pm. I had four CRC errors but the verify managed to complete. However the offending disk, when inspected later, would fail on other files supposedly CRC-checked OK, so the safe conclusion is still that any CRC error means a broken CD.

JCOPY will copy the logfile to the last-named destination just before it exits if it’s more-or-less appropriate (i.e. it’s a copy operation, CRCs are enabled, and some other things I forget). Defeat this behavior by setting CRCcopy=0”. JCOPY copies the logfile with a pre-prended “j” in a pitiful attempt to avoid clobbering something. This has the effect of making the destination media a complete record of the backup with a CRC record of all the files. Normally I’ve kept the log files on my hard drive, but of course once that’s gone — which is the only reason we’re doing all this nonsense — they won’t be there. Of course by then it won’t make much difference if the CRCs are correct, because what else will you do?

-v” is the command-line version for verify. Also, if the verify file name includes “*” or “?”, JCOPY will offer a file dialog to select which log file. Finally, during a verify if a read fails, you are given the opportunity to change the drive the verify is reading from, accommodating the common case where the CD burning occurs on a machine with a different CD drive letter as opposed to the verify machine — particularly useful for using the crc copy usually left on the destination CD. You can start-off with this mechanism in place with fakeverify=d” or command-line “-fd”. Or note that fakeverify has been enhanced to take an entire path, so you can use the crc mechanism to check subdirectories anywhere, by setting “fakeverify=c:\yourdirectory”.

If the form “-v:verifyfile” is used, then (1.) the : is removed from the name, (2.) an implied “-x” occurs — no ini file is read — and a log file in the form “jv~+.jcp” is used.

If the form is “-v::verifyfile” — TWO colons — then as above, and also the verify will restrict itself to the drive of the file; i.e., if the verify file is on drive h:, even if the verify records say d:, it won’t use that drive, but use h: instead.

The init option “BLRautoSkip=1” invokes yet another peculiar feature which will automatically skip file copy failures if (1.) the file copy fails because of inability to open the source file, and (2.) the source file name includes a “BLR” or base-line rule aka “underline” i.e. “_”. Apparently w9x-whatever does that to show you things it doesn’t like, for instance IBM graphics characters, in file names. I have a few DOS files with names like that I was trying to archive, and of course everything would fail. Note that DOS copying can deal with these files, at least this moon-phase; i.e. my fabulous OwenView idiot file viewer, or XCOPY (but of course it likes to skip the random file now and then). Anyway if you use BLRautoSkip be sure to also use a log file, and in there you’ll find evidence of this activity; search for “BLRautoSkip”. Also JCOPY’ll complain at the end of if any BLRautoSkips happened.

Then I got nervous about JCOPY just tearing-off when it starts, so I introduced a confirmation box for everything I could find, and then “AlwaysConfirm=0” option to defeat that effect.

RandomWait=240000000” is the amazing randomwait feature default — it makes the program stop and tap foot for a few minutes every 240,000,000 megabytes or so, in a probably hopless effort to cure the amazing “single file” failure mode in which large copies invariably have a single mysteriously unreadable file; or perhaps I was thinking of the Castrophic Failure Effect, where long backups fail completely with much Sturm und Drang. ... Naturally you can set RandomWait to some other mysterious value. And then there’s RandomTime, which as noted defaults to 300 aka 5 minutes. ... Weirdly this seemed to work at least once Fri 10-06-2000, where a series of 4 CDR copies of about 500 megabytes each showed 1 or 2 bad files when verified; but the fifth, with a 5 minute/380 megabyte wait, had none! It’s a trend! Of course the next two pretty-much bombed totally. This is still something of an art. ... And then with faster newer CDRs I think it’s OK now. ... I mean they still fail randomly, but this doesn’t seem to help anyway. // Thu 2/26/04 Well I think I’m seeing failures that I didn’t see before, so back in it goes. I’m imagining it’s not a too-fast-write failure, but a thing like in this particular drive, writing so long without rest heats something up that fails in some kind of global way. Or perhaps it’s the Ghost of Christmas Past....

These amazing random waits will only occur in any case if the destination of a copy is a drive not in the list defined by “NotCDR” which, as of Wednesday, July 15, 2009 12:55 pm, defaults to all drives “NotCDR=ABCDEFGHIJKLMNOPQRSTUVWXYZ”; before then, it defaulted to “C”, but I don’t use the thing for the original CDR purpose anymore anyway. ... And then, in the endless elaboration, there’s “RandomEject=38000000” which, if randomwait is non-zero, might put up a dialog suggesting you eject and reinsert the disk around 380,000,000 bytes, instead of random waiting. This may not have been particularly helpful, and defaults to 0 == none. ... The NotCDR option wound-up controlling a number of features, I believe all concerned with the main file copy function. Destination file attributes, for instance (below), are only manipulated if the destination is on the NotCDR list (and “atts=1” q.v.). The randomwait function only occurs if the destination is not in the NotCDR list. NotCDR is done this way — i.e. backwards — to make it failsafe; none of the specified effects is particularly harmful, and definitely helpful on occasion, so it’s better if they occur accidentally rather than not. Unless, of course, I never use the program anymore to packet-write to CDRs, which turned-out to problematical, at least aprés Windows 98....

NotCDR=*” produces “NotCDR=ABCDEFGHIJKLMNOPQRSTUVWXYZ”, the default.

/notcdr=c” might be the command-line rendition. “/notcdr” by itself should (probably redunantly) do the default “notcdr=ABCDEFGHIJKLMNOPQRSTUVWXYZ”; also it sets FixDotCrash=0.

ReadOnly=1” will cause all destination files to be set to readonly — but only if they’re on the NotCDR list (see above). If however the NotCDR list doesn’t contain your destination drive, JCOPY won’t try to fix the destination attributes, because that just eats-up space in the Adaptec CDR scheme. The command-line version “/readonly” will also set atts=1. None of this will work if the ini file overrides it, or the destination is a CDR drive (not on NotCDR list).

atts=0. In any case, file attributes are never copied unless the “atts=1” option is set, which tells JCOPY to copy the attributes of the source file — readonly, archive, and maybe some others, not sure — to the destinaton, but only if the destination is on the NotCDR list.

FixDotCrash=0” will defeat JCOPY’s earnest attempt to avoid crashing Adaptec DirectCD s/w when copying files with leading dots. You might be using JCOPY to copy from one drive to another and weren’t interested in fixing Adaptec software. Leading dot files are relatively rare, so the default is on.

tidy=Cleanup.bat” will run cleanup.bat when JCOPY is finished, if no error. CWDIZEd.

warning=Think Carefully” will cause the specified warning to appear at the beginning of program execution, allowing a chance to heed the warning.

In the fullness of time (around Wed 9/05/01 3:49 pm) I introduced another name alteration feature, not as dire as the leading-dot-Beta nonsense described above. This one occurs if the destination is a CDR (see “notcdr” above), the option fixbig=0” is not specified, and the filename is longer than 64 characters. Because when the Adaptec software converts such a CDR to a like-a-real-CD read-only version (as I do regularly now, reserving the CDRW media for incremental backup), it mutilates the file names to fit the 64-character ISO standard or something — or that’s my guess. So I do it, my way. Note incidentally that these file name changes are tricky; one would like to avoid accidentally clobbering another file that for some highly-unlikely reason had the same name one has just dreamed-up, but I’m not sure there’s any tidy way to do that. If you change the name until one is found that doesn’t exist on the target, you could be avoiding a previous copy you’re supposed to be clobbering — although that’s not supposed to be going on with a CDR normally, but. ... Anyway I’m not bothering with this now; the only reason I got this far is it was messing up CRC verifies when the Adaptec software changed the name. I didn’t bother fixing toobig directory names either, which I assume have the same problem. If you have a lot of these names, the advice about seeking psychological help I offered for the leading-dot file enthusiast applies. ... Mon 2/10/03 1:11 pm. Then it turns-out a semi-colon is legal in DOS, but not on the CDROM, so the “fixbig” option controls translating those to _ also.

noskipmsg=1” will suppress the informative message about how many files weren’t copies because the destination contained copies the same date or newer. “/n” is the command-line version.

noprompt=1” will suppress the initial confirmation dialog and any trailing error messages whatever. ... Generally a bad idea unless you’ve got a procedure that’s working really good and you’re tired of acknowledging the dialog. “/r” is the command-line version.

noise=1” will enable the new handy nuclear disaster air raid sound when JCOPY wants attention. Or setting it to the path of a wav file will play that file instead; the JCOPY release now includes a copy of airnukld.wav which it uses for “1”. The command-line option “/b” is equivalent to “noise=1” — if noise isn’t set to some other file. “/b-” suppresses noise no matter what “noise=”.

fakesize=1000000” tries to fake a destination size so my endless testing does not require waiting for diskettes. The fakesize gets reset whenever there’s a can’t-copy because of file too big.

sizeini=jcopysize.ini” CWDIZed. No particular reason to change the default value, which is where JCOPY saves/restores selected form size/positions.

cant_all=1” — command-line: /~ — defeats the “can’t copy; skip this one?” query for any file it can’t copy; they get logged and complained-about at the end. This option is also known as the Rose Gelb Memorial XP option, when I was copying files from one XP to another, foolish me, and of course it failed in Explorer whenever it hit a file that wouldn’t copy....

cant_skip=Z” — command-line: /~Z — would defeat the “can’t copy; skip this one?” query for any filename containing the letter “Z”. More plausible might be “cantskip=~” or some other cunning punctuation demarker so that one could, for instance, stop JCOPY from stopping for XP privilege idiocies, at least for some not particularly useful files I have control over.

cant_file=Skip_Jcopy_Maybe.txt” (command-line /c) does the cant_skip mechanism (above) via a file in the directory. If, when JCOPY can’t copy a file, then the cant_file specified file — in this case Skip_Jcopy_Maybe.txt — will be consulted, and if in this file the name of the offending file is found, it will be skipped without complaint (but will be logged). File names contained in the cant_file can contain wildcard characters. A recent innovation is to describe this file in the error message that complains; then, if you want, you can edit-up such a file with the offending name in it, and try again.

Then I got tired of all this skipping, particularly generating an error message for every backup because another of my program menagerie had an active log file, so there’s “skips_ok=1” which defaults to 1; if BLRautoSkipCount+NewerSkipped+skipped_errors is less-than-or-equal to skips_ok, no complaint.

fix64=1” — the default — when doing verify, will try a file name like “f:\Strategic_Sales_Lines_Represented_North_Jersey_Metro_New_York.doc” (filename is greater than 64 characters) as “f:\Strategic_Sales_Lines_Represented_North_Jersey_Metro_New_Yor.doc” — which restricts the filename to 64 characters by truncating the non-extension part, and is at least what one of my CDR copying programs does. Set “fix64=0” so it won’t do that.

Obsolete Debris

Counts=myfile” would save and restore the byte and file count and who knows what else into a file named myfile; CWDIZEd. This is more-or-less obsolete since the directory list “@” feature was introduced (before that I repeatedly invoked JCOPY in a batch file).

/pc:\disaster.exe or “program=disaster.exe” would run the specified program like “disaster.exe sourcedir [-r -a]”, instead of doing normal JCOPY processing. CWDIZEd. I.e. if the recurse option is true, but arconly isn’t, it’d go “disaster.exe sourcedir -r”. The ini file “pflag” specifies a file the “program=” program must delete for JCOPY to resume operations (CWDIZEd), i.e because windows is too stupid to handle that without 5 million system calls; the default is “p~flag”, and the mechanism probably doesn’t work reliably. If the ini “pshort=1” option, then the “program=” mechanism attempts to use short file names, in a pathetic effort to avoid violating command-line length restrictions. This whole thing is best left unexplored.

FormatProgram=c:\elsecoms\qdr.com” would set what might run when you click that button in media missing/full window. Might work.

Exit

To exit JCOPY, find a large solid object and SMASH your computer with it. This is the only known exit method.

... But really, in normal operation the trick is avoiding JCOPY exit; it tends to run and exit by itself, usually insisting that you click on an informative or error message (perhaps several) before that happens. If it doesn’t work that way, you may have to follow the advice above, or you can try clicking on the “X” in the upper right hand corner; or key-stroke ALT+F4 might work.

And of course there is the STOP button on the main screen, which does exactly what it says, after asking for confirmation. STOP can be used as a pause button, simply by answering NO when it asks for confirmation.

The Denouement

In the end, I don’t use JCOPY anymore for writing to Adaptec packet-written or any CDRs; but it’s still surprisingly useful for copying directories amongst my attic computer menagerie, and backing-up to various vast hard-drives, which I then copy to CDR using an average CD-writing program, in my case the often-working Ashampoo.

- 30 -