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.

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?

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.

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.

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).

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?

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.

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.