All enemies of bloat and fans of disk usage economy would undoubtedly cheer
if FDPKG modified its behavior as you suggest.
To follow up on the point about XCOPY bad behavior #2, however, I'll note
that I was using the XCOPY /E option, so it should have copied every single
sub-directory, empty o
> solved.) I tried copying the whole FDOS tree just because of my past
> experience with the problem there. I found that XCOPY copied the entire
> tree except for the PACKAGES sub-directory. The only thing remarkable I
> notice about PACKAGES is that it has 198 sub-directories.
XCOPY does not
While fiddling with the Arachne/ARA-PDF difficulty that I've been reporting
on, I found that XCOPY has some lingering problems.
The first thing I noticed was a problem copying the C:\GS tree
(GhostScript). It has sub-directories named GS.705 and FONTS. XCOPY will
only copy C:\GS\*.*. The pro
A second follow-up to my own post:
I moved everything over to a FAT16 disk, and that did not solve the problem.
(So it would seem that the revised FD FAT32 support is still good!)
I also discovered that there is a more recent version of ARA-PDF than I was
using. One previous version includes t
More on my dealings with this issue.
I did create a FD 0.9 SR2 boot disk (as updated in the successful old
installation) and still experienced the same problem.
I also downloaded a fresh copy of the recommended distro of GhostScript, and
that did not help.
Eric comments on the edition of Ghost
Under FD 0.9 SR2 with critical patches dating to 2-3 months ago, I was
running Arachne 1.90JG with the ARA-PDF plug-in (which makes use of a
certain distro of GhostScript v7.05) to view PDF files with images. (Very
nice!)
But this has failed with FD 1.0 and Arachne 1.90J1 (the newest release)
