<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 2:59 PM, Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net" target="_blank">remi@remlab.net</a>></span> wrote:</div>
<div class="gmail_quote">> <span style="font-family:arial,sans-serif;font-size:13px">AFAIK, CIFS has inodes where available.</span></div><div class="gmail_quote"><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div class="gmail_quote">I've checked this yesterday on the wire, answer is no (at least for SMB1/CIFS). There isn't any id-like field in the relevant messages (find/info/open/read).</div><div class="gmail_quote">
<div> <br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px">Your patch series effectively enforces the "collapse" mode and removes the other two. </span></div><div><span style="font-family:arial,sans-serif;font-size:13px">> Then the playlist code will merrily expand all nodes recursively at it iterates them. You </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">> need to solve this before your patch series is merged.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">The other 2 modes will be back as soon as we find a solution for the issues you raised to our awareness (and expand will be the default again). I wasn't wanting to implement it until i had some feeling that it wouldn't be useless :)</span></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""></div></blockquote><div> > <span style="font-size:13px;font-family:arial,sans-serif">Another option is to require the pf_readdir accesses to generate opaque GUIDs for their items.</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">I'm fond of that solution. Should the GUIDs be returned by the callback directly or can i store them in an info_t ? or in a new input_item_t field ?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
We can also check the ancestor directories iteratively from FileOpen(). This requires more I/O system calls, but the data should be cached by the OS anyway.</blockquote></div><div><br></div><div>If you don't mind, i'd rather go for the previous one, since this provide us with some generic solution to the problem.</div>
<div><br></div><div>Btw, Thanks for your pointers on this issue.</div><div></div></div><br></div><div class="gmail_extra">--</div><div class="gmail_extra">Julien 'Lta' BALLET.</div></div>