2
Wrong file in DocumentUltimate
Problem reported by Krzysztof Ogniewski - 7/26/2022 at 11:24 PM
Resolved
Hi,
we have been using version 4.X of the Document Ultimate library for a long time. Recently we have updated the version to the 6.4.x version and we've updated our test server, and then the production server.
Our test did not show anything wrong, but the control on the production server (with a lot of files) started to show wrong files  - apparently from cache location folder (App_Data). When user clicked the Download button, the file was ok, but not in preview. Cleaning the cache did not help, the wrong file was still served.
We had to rollback the update on our production server and switch back to 4.X version.
Can you please let us know what might be the cause of this issue? Has anyone experienced such issue? Can this be related to duplicated temp folder names, like "~1wq72z2" - are these 100% unique?
Looking forward to hearing back from you,
Kris

2 Replies

Reply to Thread
0
Brad Erickson Replied
We have had users of our web application report similar issues when we are using version 6.5.x.

Our work-around for now has been to clear the document cache and then change our Web.Config appSettings for DocumentUltimateWeb:CacheAutoTrimInterval and DocumentUltimateWeb:CacheMaxAge to have a value of "0:1" so it is constantly clearing the cache... Obviously not an ideal solution, but it seems to get it working well enough in a pinch for now, at least.

Definitely seems to be a bug that Gleamtech needs to look into resolving.
1
Cem Alacayir Replied
Employee Post Marked As Resolution
Since v6.4 we are using FileProvider API. There are many built-in file providers e.g. FileSystemFileProvider, UrlFileProvider, DataUrlFileProvider, StreamFileProvider, MemoryFileProvider, DatabaseFileProvider, AssemblyResourceFileProvider, TemporaryFileProvider.

For generating the cache key, to uniquely identify a document file, we use a string combination of file extension, file size and file date, this way cache collisions do not occur and we can resuse the cached file even if the file name before extension is changed (file1.docx and file2.docx have same cache key because it's still the same document according to file extension, file size and file date).

File providers like FileSystemFileProvider (a file on disk, on Amazon S3, on Azure) can provide file size and file date automatically however some file providers will not have this knowledge, e.g. StreamFileProvider, MemoryFileProvider (how could they know date modified of your data in a byte array or a stream?).

So for this purpose, these kind of providers have an additional property or constructor argument named DateModified and/or Size. You need to specify these to ensure you uniquely identify a document:

//Setting a MemoryFileProvider instance,
//to connect to a file in a byte array (byte[]) or a MemoryStream:
//Optional parameter dateModified: used for detailed file info, e.g. for generating better cache keys.
documentViewer.Document = new MemoryFileProvider(
    "Document.docx", //file can also be set as a relative path "SomeFolder/Document.docx".
    yourByteArray,
    yourFileDateModified //Provide dateModified to prevent cache key conflicts.
);

documentViewer.Document = new MemoryFileProvider(
    "Document.docx", //file can also be set as a relative path "SomeFolder/Document.docx".
    yourMemoryStream,
    yourFileDateModified //Provide dateModified to prevent cache key conflicts.
);

//Setting a StreamFileProvider instance,
//to connect to a file in a Stream:
//Optional parameters dateModified and size: used for detailed file info, e.g. for generating better cache keys.
documentViewer.Document = new StreamFileProvider(
    "Document.docx", //file can also be set as a relative path "SomeFolder/Document.docx".
    yourStream,
    yourFileDateModified, //Provide dateModified to prevent cache key conflicts.
    yourFileSize //Provide size only if your stream is not seekable to prevent cache key conflicts.
);

Reply to Thread