[svn] 954: Fixed ASC so that Context.input can be null.

Question

Revision: 954
Author: [email protected]
Date: 2008-03-27 08:02:13 -0700 (Thu, 27 Mar 2008)
Log Message:
Fixed ASC so that Context.input can be null. This will be the case
when the AST (abstract syntax tree) is generated.
checkintests Passed: YES
Needs QA: NO
Needs DOC: NO
API Change: NO
Code-level description of changes:
asc/semantics/CodeGenerator.java
Added checks for a null context.input before using it.
asc/parser/SelectorNode.java
Made class abstract, so SyntaxTreeDumper can be sure that it
doesn't have to handle this class directly, only it's subclasses.
asc/parser/PackageIdentifiersNode.java
Made IS_DEFINITION_FLAG private and added isDefinition() for use
by SyntaxTreeDumper and toString().
asc/embedding/LintEvaluator.java
Added checks for a null context.input before using it.
Modified Paths:
flex/sdk/trunk/modules/asc/src/java/macromedia/asc/embedding/LintEvaluator.java
flex/sdk/trunk/modules/asc/src/java/macromedia/asc/parser/PackageIdentifiersNode.java
flex/sdk/trunk/modules/asc/src/java/macromedia/asc/parser/SelectorNode.java
flex/sdk/trunk/modules/asc/src/java/macromedia/asc/semantics/CodeGenerator.java

Answer 1

I have already set it to FALSE. The solution to this will be some different OSD Task Sequence variables or a statement that it can't be made to work.
I believe that setting defines what volume will be the BOOT / OS Drive Letter. Some people were getting D:\WINDOWS as their boot volume drive letter. Setting to true means whatever was the System Drive letter (usually C) in the image will remain as such
after it was was applied, setting it to false will make the system have the same drive letter arrangement as what Windows PE detects. In my case I set it to false so that no matter what the new VHD file setup as drive C will be the system drive. I'll set it
to true on the next deployment but I expect there to be no difference, because in both PE and the WIM the installation volume is the C:.
We are talking about the DRIVE LETTERS Windows PE SCCM OSD is using for it's temporary files - and how we can manipulate these locations using OSD Task Sequence Variables, so the Apply OS doesn't try and clean up files that are not there
- and fail with an error if you have added a VHD Native Boot volume.
This OSDPreserveDriveLetter setting isn't having any effect on the problem here.
I believe that Format step is setting some task variables used by the OSD Deployment process - telling it where to store it's temporary files. However between the Format Disks and Apply operating system steps the OSD Task Sequence isn't picking up on the
fact what was the C:\ after Format HDD step is now the D:\ .
A developer who has an understanding of how the OSD boot process executes in order would be able to see what's going on here.
MCSE,MCNE,SCO,Sair Linux/GNU, Open source-enthusiast.