More testing: I pulled out a restore CD that I made from a previous FreeDOS installation. On that CD, FreeDOS DIR is able to distinguish codepage and codepage.ext, and XCOPY is able to copy the ARACHNE tree cleanly.
That CD was probably not made with CDBurnerXP -- more likely Nero or NTI. But I certainly can't recall what settings I may have chosen. Anyone know enough about CD burning for DOS compatibility to make some recommendations? --John Hupp ----- Original Message ----- From: "John Hupp" <[EMAIL PROTECTED]> To: <freedos-user@lists.sourceforge.net> Sent: Saturday, May 31, 2008 10:36 AM Subject: [Freedos-user] Make a CD in Windows that FreeDOS reads cleanly(was: Fresh XCOPY bugs) >I *seemed* to be uncovering more problems with XCOPY, like failing to copy > large chunks of the ARACHNE tree from my restore CD back to the hard > drive. > But as I said in a previous post, it now seems to me that XCOPY is not the > real problem. > > I just ran another test in which I created a CD (from Windows, on a CD-RW, > using CDBurnerXP set to Disc-At-Once) with the Arachne tree, this time > choosing ISO9660 instead of the default ISO9660/Joliet. I thought that > might take care of the problem. But under Windows I can see sub-folders > Arachne\system\codepage and codepage.ext, while FreeDOS DIR only shows two > sub-directories both named codepage. XCOPY fails to copy > arachne\system\*.* > and I think the cause is that it is balking at what it sees at that level. > > This is similar to what I reported earlier: Windows sees a folder named > Queen.sav, but XCOPY copies it to the hard drive as Queen_sa. Windows > sees > a folder named F-PROT, but XCOPY copies it to the hard drive as F_PROT, > and > none of the proper contents of the F-PROT folder get copied in, but XCOPY > starts copying in unrelated sub-folders. > > Is there another setting I need to create a CD that can be read cleanly by > FreeDOS? > > --John Hupp > > ----- Original Message ----- > From: "John Hupp" <[EMAIL PROTECTED]> > To: <freedos-user@lists.sourceforge.net> > Sent: Thursday, May 29, 2008 2:18 PM > Subject: Re: [Freedos-user] Fresh XCOPY bugs > > >> My problems with XCOPY are not as they first seemed. >> >> Windows renders the directories of interest on the CD as D:\F-PROT and >> D:\GAMES\QUEEN.SAV, but FreeDOS (at least the current version) renders >> them >> as F_PROT and QUEEN_SA. It is some comfort to find that MS-DOS 6.22 does >> the same. >> >> So file and directory name support seem to be involved, but it's not >> clear >> that it is XCOPY that is misbehaving. I see that I can MOVE C:\F_PROT >> C:\F-PROT, so the hypen is supported there. >> >> I want to reinstall those two programs from scratch to see afresh how >> folders and files are named. It also occurs to me that the CD file >> system >> may well be a factor. >> >> More on this when I can get to it. >> >> --John Hupp >> >> ----- Original Message ----- >> From: "John Hupp" <[EMAIL PROTECTED]> >> To: <freedos-user@lists.sourceforge.net> >> Sent: Wednesday, May 28, 2008 9:54 PM >> Subject: [Freedos-user] Fresh XCOPY bugs >> >> >>> I'm using XCOPY for a selective restore CD, and for most directories it >>> works fine, but I have identified a couple cases where it fails due to >>> the >>> directory name. >>> >>> Where D: is the CD: >>> >>> Case 1: >>> ------- >>> XCOPY /E /V /Y /I D:\GAMES\F-PROT C:\GAMES\F-PROT >>> >>> First of all, XCOPY asks "Does F-PROT specify a file name or directory >>> name >>> on the target?" With the /I switch, it is not supposed to ask me that >>> question, and it does not ask for copies of other directories. >>> >>> Worse, though it does create C:\GAMES\F-PROT, it does not copy any of >>> the >>> contents of the F-PROT directory. Instead, it begins copying into >>> F-PROT >>> other GAMES sub-directories: GAMES\ABUSE gets copied to >>> GAMES\F-PROT\ABUSE, >>> GAMES\DOOM to GAMES\F-PROT\DOOM, etc. >>> >>> Case 2: >>> ------- >>> XCOPY D:\GAMES\F-PROT C:\GAMES\F-PROT >>> >>> Again it asks File or Directory, and that is OK without the /I switch >>> here. >>> But after I answer Directory, XCOPY copy responds with: >>> File not found - F-PROT >>> 0 file(s) copied >>> >>> Case 3: >>> ------- >>> XCOPY D:\GAMES\QUEEN.SAV C:\GAMES\QUEEN.SAV >>> >>> The response is similar to Case 1, except that XCOPY does not ask File >>> or >>> Directory. Instead, it copies none of the F-PROT contents but >>> immediately >>> begins copying other GAMES sub-directories into GAMES\F-PROT (as in Case >>> 1). >>> >>> Case 4: >>> ------- >>> XCOPY D:\GAMES\QUEEN.SAV C:\GAMES\QUEEN.SAV >>> >>> The response is exactly the same as for Case 2. >>> >>> --John Hupp >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Freedos-user mailing list >>> Freedos-user@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/freedos-user >>> >>> >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
