Try our conversational search powered by Generative AI!

Filehandling: VirtualPathVersioningProvider vs. VirtualPathNativeProvider vs. UnifiedFile

The file handling in EPiServer are somewhat confusing (at least for me ;-). As the subject says how are these three compared to each other? When should the different be used? And why? Are there any good descriptions anywhere of how, why and when the different should be used? What I actually are trying to achieve is to move a lot of files from another EPiServer (older version: 4.51) and try to update the fileinformation besides the actual fileinfo (comments, keywords etc.), and I do have some trouble understanding what "filesystem" to use to achieve this. The old version used this in web.config: The new site (CMS) uses: From my meager understanding, I have till now uncovered that it might be that the filesystem should have been configured more like the following to use file information in XForm: A filesystem with VirtualPathVersioningProvider will handle the XForms correctly, as the VirtualPathNativeProvider does not save or read back the information available when editing file summary. Am I thinking or doing it the wrong way and should I be using anything else than VirtualPathVersioningProvider/VirtualPathNativeProvider for achieveing the goal of moving files from 4.51 to CMS and maintaining the extended file information?
Sep 25, 2007 12:08
Hi The file handling in EPiServer CMS is one area that has been rewritten to confirm to the provider model (VirtualPathProviders or VPPs) that ASP.NET offers. The VPPs that we offers in EPiServer CMS is VirtualPathNativeProvider and VirtualPathVersioningProvider. VirtualPathNativeProvider is storing files/folders in the physical file system in the same strucure as its virtual representation. A link to a file served by a VirtualPathNativeProvider will be stored as a traditional link, compared to a permanent link (e.g. ~/link/.doc). A consequence of this is that files served by VirtualPathNativeProvider will not be included in an export package. So VirtualPathNativeProvider is a good candidate if you need to be able to edit files from e.g. Windows Explorer and the files doesn't need to be exportable (it is though easy to manually export files, it's just an xCopy since file system structure is an exact mapping from virtual structure). VirtualPathVersioningProvider is storing files/folders in the physical file system in a loadbalanced strucure. A link to a file served by a VirtualPathVersioningProvider will be stored as a permanent link (e.g. ~/link/.doc) which make them exportable. This provider is the recommended unless you must support file editing through e.g Windows Explorer. In the release version of EPiServer CMS there is no support to do a complete upgrade from EPiServer 4.6x to EPiServer CMS. There is however a limited support of importing "old" .epi4 files to EPiServer CMS. One limitation is that file summarys are not preserved, as you have noticed. We will in a relatively soon future deliver a migration tool that will support migration from EPiServer 4.6x to EPiServer CMS. The feature set for this migration tool is not yet fully specified. Migration of file summaries is something that we will consider when deciding the final feature set.
Sep 27, 2007 14:52
The reason for trying to get this somewhat clearer is the following: When handling files in EPiServer CMS in File management and you have defined and are administering files in /FileArchive the confusion arises in the moment you get the possibility to edit/change/add Filesummary which in the next moment is not saved or available for edit later on. No error message etc. This is rather inconsistent behaviour to allow the file summary to be edited/added when the filesummary are not supported and thus arises the confusion. To make the question possibly even easier and more to the point: Is it possible to make the edited summary of the VirtualPathNativeProvider-files persistent? If yes what are the circumstances this may occur and what is necessary of configuration and/or coding?
Sep 27, 2007 15:58
I can agree that it would be more clearer if the UI did not offer possibilty to set summary values for Providers that does not support it. I will make a issue in our bug system on this issue. It is not possible to configure the VirtualPathNativeProvider to support summary. You can however create an own custom provider that inherits VirtualPathNativeProvider, you will also need to create custom classes that inherits NativeFile and NativeDirectory. In your custom class that inherits NativeFile you should override Summary property so it persist the summary to some media (file, db etc). In your implementations of the provider and directory classes you only need to make changes so those returns your custom classes instead of NativeFile and NativeDirectory.
Sep 28, 2007 10:53
I have "solved" this Kafkaesk handling of files just by letting it use the VersioningDirectory/-File. This accomplish me using the earlier summaries by reading them directly from the database and then recreate them. On the other hand I was rather pissed to understand that you have to create a file in a newly created directory to make the directory functioning in filemanager. Should this also be reported as a bug or have I been doing unspeakable acts in my code? The last rant is rather easy to recreate: 1) Make VersioningProvider-directory and make sure IIS have all possible rights to handle this folder 2) Run the following code: private void CreateDir() { UnifiedDirectory ud = System.Web.Hosting.HostingEnvironment.VirtualPathProvider.GetDirectory("Mynewversioningfolder") as UnifiedDirectory; UnifiedDirectory udnew = ud.CreateSubdirectory("MyNewFolder"); } This folder will appear in the filemanager, but will not be mangeable in any way (you cant even delete it, unless you do that with code). To make the above folder appear AND WORKING, replace CreateDir with the following code: private void CreateToDir() { UnifiedDirectory ud = System.Web.Hosting.HostingEnvironment.VirtualPathProvider.GetDirectory("Myversioningfolder") as UnifiedDirectory; UnifiedDirectory udnew = ud.CreateSubdirectory("MyNewFolder"); UnifiedFile uf = udnew.CreateFile("wtf-is-this-really-necessary.gif"); uf.Delete(); } Is this by some weird design decisions and does it have some explanation which are coherent and if so, I would on behalf of all the other who do not want to spend lots of time guessing how to do creation of directories with Versioning-filesystem, beg you to update the documentation with this pitfall.
Oct 01, 2007 11:25
I think there might be a misunderstand here on how FileManager works. In file manager the toolbar (with delete, rename etc.) acts upon the items in a folder(or more exact the selected items in a folder) not the folder it self. Say e.g. that you want to rename or delete a "/Documents/MyFolder/" then you would navigate to folder "Documents" select folder "MyFolder" and choose rename or delete. The exception is the toolbutton "Set access rights" which operates on the current folder not selected items (because access rights are set on folders not files).
Oct 05, 2007 8:23
The question here was not related to how the Filemanager works. The answer was not in any way connected to the question. My question was: When programatically creating folders why is it that they have to get a file created in the folder before the folder is accessible in anyway in Filemanager? If not the file is created in the same folder then the folder does not get created at disk and as such the Filemanager does not understand what to do. If on the other hand the file is created (and deleted in the same operation) the folder is created and as such the Filemanager understands it and the folder is accessible as supposed. I do kind of understand that there has to be a folder at disk for the Filemanager to work, but why is it then not created on disk but only in the database. The problem is verified only in VersioningDirectory. Did this make it any clearer to understand the problem? Is it then possible to get an answer related to if I am doing something wrong or miss some code to make this work, or that my workaround with creating a file in the folder is actually a bug in VersioningDirectory?
Oct 05, 2007 16:12
I cant reproduce the error you describe. Are you running the released version of EPiServer CMS 5? When I try the following code UnifiedDirectory dir = HostingEnvironment.VirtualPathProvider.GetDirectory("/Documents/Subfolder/") as UnifiedDirectory; if (!HostingEnvironment.VirtualPathProvider.DirectoryExists("/Documents/Subfolder/sub/")) { dir.CreateSubdirectory("sub"); } a directory sub is created. And in File Manager the folder is fully functional.
Oct 12, 2007 10:23
I think I am using the latest version of EPiServer (.dll): v5.1.422.4. I tried recreating it with a new instance of a directory, and managed not to recreate it myself just now.
Oct 15, 2007 9:24
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.