Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

SVS 2.X SDK Guide Part 7: Files and Registry

Created: 13 Jun 2008 • Updated: 29 Jul 2010
Language Translations
Jordan's picture
0 0 Votes
Login to vote

A common problem people have with SVS is trying to add new files to a layer. It's very common for someone to try to just add, via Windows Explorer, to the virtualized path. Experienced SVS users know this won't work since the virtualized path is just that, virtual, and while the file will get moved it won't get into the layer itself. So, when you export, that moved file won't be in the package.

To get around this people use SVSadmin or navigate through the FSLRDR directory. This can be hard if you have a lot of layers since you need to know what magic number your layer is and SVS can be slow going if you have lots of files that need to be moved or need to affect more then one layer.

The SDK provides some useful functions for dealing with files in a SVS layer. This article will also briefly cover some of the registry functions of the SDK as well - but not as in depth because most are just slightly modified versions of the standard windows registry API.

Changes to the FSL2 Class

Several methods have been added.

You can download the newest version of the FSL2 Class from the download portal.

Working with Files

The first thing you need to know is the path of where the file is, or will be, that you want to do something with. There are a few things you need to do to get this path.

Getting the Path

The first step is using layer attributes, discussed in depth in Part 4, and will return the root path to the FSLRDR directory that your layer is in. So, for example, getting VzLayerAttributeFileRedirect could return C:\FSLRDR\3\ but you'd still need to know the rest of the path that says where in the file system the file should go.

FSL2VariablizePath

public static extern UInt32 variablizePath
 (
  string path,
  [MarshalAs(UnmanagedType.LPStr)] StringBuilder resultPath,
  UInt32 cbResultPath
 );

VariablizePath takes a path, say C:\Documents and Settings\MyUser\Desktop\SVS and returns [_B_]Desktop[_E_]\SVS which you can append to the File Redirect you got by using the layer attribute method and get the full redirect path of your directory: C:\FSLRDR\3\[_B_]Desktop[_E_]\SVS. Like all other string based methods the size of the stringbuilder is 64.

FSL2GetFullNonLayerPath

public static extern UInt32 getFullNonLayerPath
 (
  string fslGuid,
  string path,
  [MarshalAs(UnmanagedType.LPStr)] StringBuilder nonLayerPath,
  UInt32 cbNonLayerPath
 );

GetFullNonLayerPath is poorly named because that's actually what we're getting, this function combines what you do with FSL2VariablizePath and getting the file redirect from via layer attributes. If you pass in C:\Documents and Settings\MyUser\Desktop\SVS along with the correct GUID you will get back C:\FSLRDR\3\[_B_]Desktop[_E_]\SVS. Likewise if you pass in [_B_]Desktop[_E_]\SVS you'll get back the full FLSRDR path.

Copying Files

The SDK contains a function named FSL2AddFile which takes a file and copies it into the path you define. This function is not in the FSL2 Class because it's really not that useful to .Net users. .Net can use File.Copy() instead for the same result with less work. To use FSL2AddFile, for the C++ users reading this, you need to pass in a GUID, the path to the file to be copied and then path to the copy location. You'll also need to create a callback for the function and pass in some other pointers. FSL2AddFile then gets the layer's file redirect path and variablizes the path. While this is a useful function it's less effort to just grab the file redirect and variablize the path using the methods above than trying to create and manage the callback if you using .Net.

The Read-Only Layer

The default GUID of a layer is for the Read/Write layer, so if you want to add to the Read-Only layer you'll have to grab the layer's peer using one of the two layer attribute methods.

Other File Path Functions

FSL2DevariablizePath

public static extern UInt32 devariablizePath
 (
  string path,
  [MarshalAs(UnmanagedType.LPStr)] StringBuilder resultPath,
  UInt32 cbResultPath
 );

DevariablizePath is the opposite of VariablizePath, it will take C:\FSLRDR\3\[_B_]Desktop[_E_]\SVS and return C:\Documents and Settings\MyUser\Desktop\SVS.

FSL2DecorateVariablizePath

public static extern UInt32 decorateVariablizedPath
 (
  [MarshalAs(UnmanagedType.LPStr)] StringBuilder path,
  UInt32 cbPath,
  bool decorateForDisplay,
  string decoratedVariableStart,
  string decoratedVariableEnd
 );

DecorateVariablizedPath is an intresting function, it takes a variablized path such as [_B_]Desktop[_E_] and replaces then[_B_] and [_E_] with what ever you place in decoratedVariableStart ([_B_]) and decoratedVariableEnd ([_E_]) if you pass in a true for DecorateForDisplay. This is most commonly used to pass in a "[" and "]" respectively to get a system variable name. Passing in false will take a system variable, [Desktop], and variablize it.

Deleting Files

public static extern UInt32 deleteFile
 (
  string fslGUID,
  string srcPath
 );

To delete a file just pass in the path and the GUID and deleteFile will do the rest.

Renaming Files

public static extern UInt32 renameFile
 (
  string fslGUID,
  [MarshalAs(UnmanagedType.LPStr)] StringBuilder srcPath,
  string destPath
 );
 

To rename you pass in a GUID and a new rename name and then the original file as a string builder.

Working with Directories

There's only one function dealing with directories in the SDK and that's FSL2CreateDirectory which mirrors closely the C++ createDirectory.

public static extern bool createDirectory
 (
  string fslGUID,
  string fullDirectoryName,
  System.IntPtr lpSecurityAttributes
 );

CreateDirectory takes in a GUID and a directory name (full path) and any security attributes you want for the directory, use Null if you want inherited or don't know how to get the securityAttributes. It would probably be easier to use .Net's Directory.Create() along with GetFullNonLayerPath then it would be to use this function with .Net because of the security attributes needed, but it's here if you want to use it.

Registry

There are a lot of registry functions in the SDK, however they're all just copies of standard windows registry functions. There are some that require a GUID and will affect the registry redirect area of your layer. These are FSL2RegCreateKeyEX and FSL2OpenKeyEX, but all the rest are the same as what you'd get in Win32.

Because of that I'm not placing these functions into the FSL2 Class, for the copies or FLS2RegCreateKeyEX and FSL2OpenKeyEX. The latter two I'm not adding because there's a lot more work to use those functions than it would be to get the registry redirect area from a layer's properties and use the default .Net registry methods. For the C++ versions you need to get a registry handle to pass in and you get one back which is more effort than it's worth with .Net.

Seeing it in Action

The example for this article will cover adding a file to a specific location inside a layer. We're going to want three arguments, one for the layer GUID, one for the file to copy and one for the destination.

public class Program {
 static void Main(string[] args) {
 if(args.Length!=3){
  Console.WriteLine("CopytoLayer takes three arguments: a GUID, the original file and a destination path.");
  }else{
  String myGuid=args[0];
  String myFile = args[1];
  Straing myPath = args[2];
  StringBuilder myCopyPath = new StringBuilder(64);
  UInt32 bufferSize = 64;
  FSL2.getFullNonLayerPath(myGuid, myPath, myCopyPath, bufferSize);
  FileInfo myFileInfo = new FileInfo(myFile);
myFileInfo.CopyTo(myCopyPath, true);

 }
 }

}

This is a pretty simple program. It takes the GUID, needed for getFullNonLayerPath, the path of the file, and the copy path and then uses the GUID to get the file redirect path equivalent of CopyPath. Once that is done we create a FileInfo object of our file so we can copy it to the variablized path we just got. The True in myFileInfo.CopyTo is a Boolean for overwriting existing files.

Of course the next step for an application like this would be to allow for a copy of a whole directory. However .Net doesn't have a function that will copy all the subfolders and files for you so you'll need to code one yourself - or just copy the code off of the MSDN which has a sample script that will do recursive directory copying. Just do a search for Basic file I/O for a list of how to work with files and directories and the above mentioned sample script.

Conclusion

Most of SVS's file, directory and registry functions are writing solely for the C++ environment and aren't worth using in .Net because it's easier to just use .Net's managed functions instead. Even with using the functions in the SDK there's not a really easy way to manage files or the registry with .Net because of the difference in how C++ handles the file system and how .Net does. However, having access to getFullNonLayerPath is very useful and worth making note of. Part Eight will cover a mix of things like ignoring processes, checking permissions and so on.

Remember that future versions will be listed in the FSL2 Class Portal where the FSL2 class is available for download. Be sure to subscribe to that thread which will inform you of any new articles and updates to the class.

Return to the Virtualization SDK Book