CimFS folder structure

%3CLINGO-SUB%20id%3D%22lingo-sub-2544864%22%20slang%3D%22en-US%22%3ECimFS%20folder%20structure%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2544864%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20conversion%20of%20MSIX%20packages%20to%20CimFS%20includes%20defining%20a%20%22root%20folder%22%2C%20the%20name%20of%20which%20appears%20irrelevant.%26nbsp%3B%20If%20I%20call%20it%20%22George%22%2C%20when%20deployed%2C%20this%20creates%20a%20folder%20structure%20that%20looks%20like%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%5C%5C%3F%5CVolume%7BGUID%7D%5CGeorge%5C%7BFullPackageFamilyName%7D%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3Eas%20the%20actual%20%22root%20folder%22%20of%20the%20original%20MSIX%20package%20(the%20one%20that%20contains%20the%20metadata%20files).%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThis%20raises%20the%20question%20as%20to%20whether%20multiple%20packages%20may%20be%20included%20within%20the%20CIM%20image%20(under%20%22George%22)%2C%20and%20if%20so%20what%20relationships%20are%20expected%2Fallowed.%26nbsp%3B%20For%20example%2C%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3EMight%20it%20be%20possible%20to%20have%20a%20CIM%20that%20is%20actually%20a%20bundle%20(and%20treated%20as%20one%20upon%20install)%3F%3C%2FLI%3E%0A%3CLI%3EIs%20it%20possible%20for%20the%20CIM%20to%20contain%20dependency%20packages%3F%3C%2FLI%3E%0A%3CLI%3EIs%20it%20possible%20for%20the%20CIM%20to%20contain%20a%20package%20and%20a%20modification%20package%20to%20it%3F%3C%2FLI%3E%0A%3CLI%3EIs%20it%20possible%20for%20the%20CIM%20to%20contain%20two%20separate%20packages%20that%20would%20be%20brought%20together%20in%20a%20Shared%20Package%20Container%2C%20either%20explicitly%20or%20implicitly%3F%3C%2FLI%3E%0A%3CLI%3EIs%20it%20possible%20to%20put%20a%20bunch%20of%20common%20packages%20delivered%20to%20most%20users%20into%20a%20single%20CIM%3F%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3EAlso%2C%20is%20there%20a%20requirement%20that%20%7BFullPackageFamilyName%7D%20be%20the%20name%20of%20the%20second%20level%20folder%20or%20is%20that%20just%20what%20the%20conversion%20tools%20currently%20do%20and%20the%20name%20of%20that%20folder%20is%20also%20irrelevant%3F%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EEven%20if%20not%20available%20today%2C%20as%20I'm%20building%20CIM%20based%20tooling%20I'd%20like%20to%20know%20more%20about%20what%20could%20be%20or%20is%20clearly%20not%20in%20scope%20for%20the%20future%20in%20this%20regard.%3C%2FP%3E%3C%2FLINGO-BODY%3E
MVP

The conversion of MSIX packages to CimFS includes defining a "root folder", the name of which appears irrelevant.  If I call it "George", when deployed, this creates a folder structure that looks like:

 

\\?\Volume{GUID}\George\{FullPackageFamilyName}

 

as the actual "root folder" of the original MSIX package (the one that contains the metadata files).

 

This raises the question as to whether multiple packages may be included within the CIM image (under "George"), and if so what relationships are expected/allowed.  For example,

  • Might it be possible to have a CIM that is actually a bundle (and treated as one upon install)?
  • Is it possible for the CIM to contain dependency packages?
  • Is it possible for the CIM to contain a package and a modification package to it?
  • Is it possible for the CIM to contain two separate packages that would be brought together in a Shared Package Container, either explicitly or implicitly?
  • Is it possible to put a bunch of common packages delivered to most users into a single CIM?

Also, is there a requirement that {FullPackageFamilyName} be the name of the second level folder or is that just what the conversion tools currently do and the name of that folder is also irrelevant?  As the mounting process hides that name from MSIX I'm guessing the latter, unless there is a plan for AppInstaller to use it in decision logic.

 

Even if not available today, as I'm building CIM based tooling I'd like to know more about what could be or is clearly not in scope for the future in this regard.

0 Replies