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 <[email protected]> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
