On 05/15/2012 03:50 PM, Daniel Shahaf wrote:
>> }
>> }
>>
>> - /* Handle property modifications. */
>> if (! do_delete || do_add)
>> {
>> - if (change->prop_mod)
>> + /* Handle property modifications.
>> +
>> + Note that this needs to happen in the "copy from a file or
>> + directory we aren't allowed to see" case since otherwise the
>> + caller will have no way to actually get those properties
>> + which they are apparently allowed to see. */
>> + if (change->prop_mod || (change->copyfrom_path && ! copyfrom_path))
>
> Why is change->copyfrom_path initialized?
>
> You don't check change->copyfrom_known, and fill_copyfrom() is called in
> the 'do_add' case but not in the '! do_delete && ! do_add' case.
I copied code from the /* Handle textual modifications */ block just below
this. If there's a problem with the copyfrom initialization here, it
predates my edits.
My guess is that this code has worked fine because while
change->copyfrom_path may not be "valid" (in the semantic,
information-carrying sense) it is also not filled with random junk. FSFS
always fills it with valid stuff; BDB initializes the whole CHANGE structure
with zeroes. Still, we clearly need to locally ensure that the bits are
valid. I'll do so in a subsequent commit.
> And, BTW, did you revert the docstring patch to fill_copyfrom() part of
> r1338803? I think it should stay.
I re-added it in r1339154. Thanks for pointing that out.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-05-16 15:32:36 CEST