London Dev Meetup Rescheduled! Due to unavoidable reasons, the event has been moved to 21st May. Speakers remain the same—any changes will be communicated. Seats are limited—register here to secure your spot!
AI OnAI Off
Weird guid path to VPP files
Hi,
yes, that is the internal representation that are stored in HTML to make the links permanent. Can you share a more detailed description on where you see these paths and what problems this is causing ?
Jul 07, 2010 15:36
We haven't been able to identify when this occurs, the exact same function run three times can generate two valid links and one of the internal ones in my original post.
I think the problem with translation to external format stems from the fact that file with the guid above doesn't seem to exist... This is the code:
UnifiedFile uf = ud.CreateFile(fileName);
//we would very much like to use the dispose pattern here, but unfortunately EpiServer throws error when we do that...
using (Stream fs = uf.Open(FileMode.OpenOrCreate))
{
byte[] data = File.ReadAllBytes(sourceFile);
fs.Write(data, 0, data.Length);
}
return VirtualPathUtility.Combine(Settings.Instance.SiteUrl.AbsolutePath, uf.VirtualPath);
UnifiedFile uf = ud.CreateFile(fileName);
using (Stream fs = uf.Open(FileMode.OpenOrCreate))
{
byte[] data = File.ReadAllBytes(sourceFile);
fs.Write(data, 0, data.Length);
}
return VirtualPathUtility.Combine(Settings.Instance.SiteUrl.AbsolutePath, uf.VirtualPath);
This means the UnifiedFile doesn't throw any errors, writes the file correctly (it seems - it's present in PageFiles when browsed from edit mode) but returns the wrong VirtualPath...
Jul 07, 2010 15:51
Ok, so the file is present in edit mode but not as a physical file in the PageFiles folder in Windows ? (the folder structure is based on the guid)
Jul 07, 2010 16:18
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.
When programmatically adding files to a virtual PageFiles folder, we occasionally get links that look like this:
~/link/bf35e11da392462086720cd6e8a60dff.pdf
These links don't work. I'm guessing the above is some sort of internal representation of the path, but can't be translated into a web path.
This occurs in both CMS5 and CMS6...