On Fri, Sep 28, 2012 at 4:26 AM, Adrian Buehlmann <span dir="ltr"><<a href="mailto:adrian@cadifra.com" target="_blank">adrian@cadifra.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":4o">V11 of experiment for a simpler path encoding for hashed paths (for "fncache2")<br></div></blockquote></div><br><div>Right now, your patch and mine make a lot of unrepresentable characters safe by mapping them to a single character, '~' 0x7e. This changes the sort order of hash-encoded names in undesirable ways: for instance, it means that files that originally began with dot or space will, once hash-encoded, now sort *after* files that begin with alphanumeric characters.</div>
<div><br></div><div>With a hot disk cache, the effect will obviously be negligible, but with a cold cache, it will lead to extra disk head seeks.</div><div><br></div><div>That possibility can easily be mitigated: instead of mapping all unrepresentable characters to '~', just map them to a safe character that is lexically close instead. For example, space 0x20 could be mapped to '!' 0x21, '.' 0x2e to could be mapped to ',' 0x2c, and likewise for unsafe names such as "aux" ("auy").</div>
<div><br></div><div>This seems somewhat important to me.</div>