Minor comment on XPCREATE.CMD

[MindMaster]

Hi,

I noticed in the :CHECKSRC section of XPCREATE.CMD that there is an XCOPY command without the /Y and as a result, a prompt appears asking to confirm the copy. I would like to suggest that the command be updated to suppress confirmation.

Thanks,

Mark

P.S. Great Job!

[GreenMachine]

Welcome to MSFN, MindMaster!

As hard as it may be to believe, most every command and switch in XPCREATE has a reason to be. In this case, you are only getting the error as XPCREATE is creating a local copy of the source where there are already files. It was not designed for that, and you are the first to notice/report it. I will have to re-think what I would like to happen in that case, but I am tending more towards erroring out, with a message to the tune of "You have chosen a non-empty directory to copy your source files to. Please delete these files and try again." The reason for this is the same reason I insist on starting with an original Microsoft Windows CD: I want to start from a known point. There is already enough room for error, so I want to eliminate as many unknowns as possible.

My question to you is: Did you intend to copy the source somewhere where there were already files? If so, why. If not, how did this come about?

Thanks for your help!

[MindMaster]

Hi,

I wasn't copying it anywhere intentionally. For some reason that I have not yet determined, CDSOURCE was the target and there were still files there. One time this happened because I was browsing in the directory while XPCREATE.CMD was executing but this only happened once.

At the moment I am running XPCREATE repeatedly as fast as my computer will test it in an attempt to get the SATA drivers working without success. During these iterations omitting the XPSOURCE entry seemed to cause the problem (along with varying to both YES and NO for COPYSOURCE perhaps?). I will continue to investigate and pass on any information I can ascertain but recently I wrapped XPCREATE.CMD in my own BAT file and simply deleted the CDSOURCE directory before running XPCREATE.BAT so I don't see this problem any more.

While we are on the topic of minor points (let me say again this is a great utility) consider:

1. If the BOOT directory has not been created and there is no entry BOOTIMGFILE then the script appears to attempt to move it to the BOOT directory without first creating it thus causing a failure.

2. Displaying all the files that are copied significantly slows down a copy operation for xcopy. I would like to recommend the /Q option be used for large xcopy commands.

3. Lastly, if I have my destination RW CD in the drive D (and/or I don't specify a destination) and the destination was a previous failed XPCREATE run, then the copy operation occurs from the destination disk rather than the source disk. One way around this to consider would be to perform the CDRW erase before the source copy. Obvously explicitly specifying the source location is another way around it but many folks may not realize that the destination CD is being used as the source and that could be confusing. (Does this make sense at all?)

Thanks for all your hard work!

Edited September 18, 2004 by MindMaster

[GreenMachine]

Thanks, MindMaster, for the clear descriptions. After reading your post, I have made a few modifications to the "in progress" version. (Lucky you caught me just before my quarterly release!)

0) After pondering, I decided to delete the CDSOURCE directory before copying files to it. If the delete does not work (e.g. some wiseguy has it open in Explorer!), XPCREATE errors out.

1) XPCREATE now creates all needed directories by default at the begining of EVERY run. That should eliminate this problem.

2) I'll have to do some time trials, but while I know that displaying DOES add some time, I will need numbers to be convinced it saves more than, say, 30 seconds. Given the time needed for the rest of the XPCREATION, a 30 second gain does not seem important to me. I'll keep it in mind, but before seeing a real savings, I'm leaving it alone. I find the copy phase too long to not have some sort of visible progress, even if the window needs to be maximized to see. A big part of my decision has to do with the fact that I often find myself looking at that window, and me being my favorite client ...

3) After a few readings, this made sense. I have changed XPCREATE as you suggested to erase the CD/DVD at the begining. I just wonder how long it will be before someone complains that I erased thier CD. However, I have stated many, many times that ONLY ORIGINAL MICROSOFT WINDOWS CDS should be used as source. These I cannot erase ... Before a CD/DVD is erased, the user must change both the CDERASE and CDBURNER values. Be forewarned ...

Again, thanks for the suggestions (and for not posting modified XPCREATE code!)

[MindMaster]

0. This seems like the correct approach to me... this was my approach in my batch file wrapper.

1. Excellent!

2. No problem.... where it really became a problem for me was when I was prompted to overwrite. Since you dealing with this the /Q is perhaps insignificant as you suspect.

3. Hey, if someone has the CDERASE setting set to true they can't very well request that you don't erase the CD now can they.

No way I am posting modified code.... to change this script and then upgrade to a newer version in the future is way beyond my tolerance level. I went to great lengths to add my own customizations via other ways than script modifications. In the end I thought I needed to actually modify it but eventually I realized that I had misunderstood how it worked and should, therefore, adjust my expectations.

One more consideration (not as minor):

Allow for additional files (read Mass Storage Device Drivers) to be placed into the FILESCD\i386 directory and copied into the i386 directory on CD. This would allow one to slipstream files that you have not handled explicitly. If a TXTSETUP.SIF file is there you could use it as the master file to which you place your RAID/DRIVER magic. Just as you do already with the WINNT.SIF file. Just a thought for the future.

Later,

Me

P.S. Writing this amount of batch script code is truly amazing. This seems like an ideal task for MSBuild (once it was part of the OS) and your script is significantly more complex than most build scripts I ever created.

[GreenMachine]

... One more consideration (not as minor):

Allow for additional files (read Mass Storage Device Drivers) to be placed into the FILESCD\i386 directory and copied into the i386 directory on CD.  This would allow one to slipstream files that you have not handled explicitly.  If a TXTSETUP.SIF file is there you could use it as the master file to which you place your RAID/DRIVER magic.   Just as you do already with the WINNT.SIF file.  Just a thought for the future. ...

I'm not quite sure I understand ...

In the next version, I allow the user to add their own MassStorageDevice driver files, where the following *.OEM file is added, and the .SYS driver file placed somewhere in the DRIVERSDIR path.

[SourceDisksFiles] 
si3112.sys = 1,,,,,,3_,4,1 

[HardwareIdsDatabase] 
PCI\VEN_1095&DEV_3112&SUBSYS_31121095 = "Si3112" 

[SCSI.load] 
si3112 = si3112.sys,4 

[SCSI] 
si3112 = "Silicon Image SiI 3112 SATALink Controller"

This information is added to TXTSETUP.SIF. Is that what you mean?

Anything more will need to wait: I have already added more to the forthcoming release than I like to, and now just want to test it and get it out the door.

[MindMaster]

Excellent... Even better than what I was proposing!

[GreenMachine]

Pheeeew! I think I'll close the door here on any more modifications ...