On Sun, Feb 5, 2012 at 7:49 PM, huang jun <hjwsm1989@xxxxxxxxx> wrote:
> 2012/2/6 Yehuda Sadeh Weinraub <yehudasa@xxxxxxxxx>:
>> On Sun, Feb 5, 2012 at 6:21 PM, huang jun <hjwsm1989@xxxxxxxxx> wrote:
>>> hi, all
>>> Recently, we use s3 client cyberduck to add some files to RADOS, it
>>> seems doesn't support objects named with prefix of '_'.
>>> eg, if we put a object named "_test"(1 prefix "_") in bucket TEST, it
>>> will store in RADOS in another name "___test"(3 prefix "_").
>>> but if we list bucket TEST, it sends op whoes oid is "__test"(2
>>> prefix "_"), result the RADOS return ENOENT err.
>>
>> That's a bug. From what I can tell, the bucket listing is broken (when
>> object name starts with underscore). I created bug #2025 in the ceph
>> tracker.
>>
>>> we trace the debug log,and found where it comes from:
>>> in "translate_raw_obj" func of rgw_common.h,
>>> if (obj.size() >= 2 && obj[1] == '_') {
>>> obj = obj.substr(1);
>>> return true;
>>> }
>>> why cut the obj name?
>>
>> The underscore serves as an escape character. Some object are created
>> in a separate namespace, and the format for those objects is:
>>
>> _<namespace>_<obj name>
>>
>> These objects reside in the bucket, but may not be listable, and may
>> not be accounted in the bucket stats.
>>
>>> what is "string ns" in struct rgw_obj doing here? Can't we just use
>>> the origin obj name that passed object_name verfication?
>>
>> 'ns' is the namespace. I'm not sure what check you're pointing at, but
>> we do need to handle the case where an object has a namespace
>> different than the default one.
>>
> I mean here is "validate_object_name" when init the rgw_handler.
> i think we should do nothing if the "ns" string is empty.
> i have done a test, it works well except that when we download a file
> "_test' (size is 20B)
> the yberduck returns error "unexpected end of ZLIB input stream".
There are actually two different issues. One is that we don't escape
the preceding underscore correctly (adding two underscores instead of
one), and the second issue is that we don't return the translated
object when listing a bucket.
I pushed a fix for those issues to the ceph master branch. The only
caveat is that you can't access now any object that was uploaded that
started with underscore. If possible, it'd be best to remove those
objects before applying the fix. Let me know if that's a real issue.
Thanks,
Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
