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