3
Vote

Fails if cache keys are not also legal filenames

description

e.g. The following gives an error:

FileCache fc = new FileCache();
fc["http://site.name/path1?arg1"] = "1";

I've also had instances of retrieving a value from the cache when no such key was stored due to them mapping to the same filename by file.Open.

A more advanced storage strategy is required - perhaps take a hash of the key and use that as the filename and if there is a collision add a numeric suffix and then store the actual filename inside the file to verify the correct item has been retrieved and try the next one if there is a clash and the wrong one was opened first.

comments

adamcarter wrote May 7, 2014 at 3:30 PM

I assume that you're issue comes from Windows' case insensitivity?

mabakay wrote May 10, 2014 at 8:56 AM

Not only filesystem case insensitivity, but the class should allow as a key also characters not supported by filesystem too.

E.g.
string key = "item cache key name::/@#$%^!";
string fileName = BitConverter.ToString(Encoding.UTF8.GetBytes(key)).Replace("-", string.Empty);

wrote May 10, 2014 at 9:34 AM

adamcarter wrote May 11, 2014 at 5:51 PM

This is a good idea. I'll be on the to do list for the next release.

paulhickman wrote May 12, 2014 at 7:24 PM

To fully implement the object cache spec, you also have to allow for cases where the string is too long for the filesystem path limit. A system where a hash of the string is used to generate the filename, and the actual key string is stored in one of the files is the most reliable.

mabakay wrote May 13, 2014 at 5:28 AM

Hash from string is good because file name will be shorter. Either way key length should have limit. It would prevent from making keys larger than associated value ~100-200 max key length.

wrote Sep 14, 2015 at 9:46 AM