Bug #2285
closed
libcephfs: failure with empty name components
Added by Yehuda Sadeh about 12 years ago.
Updated over 11 years ago.
Description
the following in client/testceph.cc fails:
// test empty name components
my_fd = ret = ceph_open(cmount, "readdir_test//opened_file_1", O_RDONLY, 0666);
ceph_open O_RDONLY error: (2) No such file or directory
- Status changed from New to In Progress
Oddly, this looks like it's a race. I can't reproduce it with any client debugging on...
- Status changed from In Progress to 12
- Priority changed from Normal to Low
Yep, it's client-local; there's no request to the MDS for this either.
Guess that means we don't care right now?
- Assignee changed from Greg Farnum to Sam Lang
I noticed that the above test doesn't have O_CREAT, not sure if the file already existed in previous tests. The following test seems to behave as expected for me though: https://gist.github.com/3761908
I suspect that differs from his failure because the paths are already cached on the client. Try creating the file, unmounting, remounting, and then doing the open?
I tested this by working around #3186, first creating the file and then in a separate test running ceph_open as the original test did (with just O_RDONLY). The only difference with the above test is the preceding slash. "/readdir_test//opened_file_1" succeeds, but "readdir_test//opened_file_1" fails with ENOENT. This looks like correct behavior.
- Status changed from 12 to Fix Under Review
This was probably caused by the memory error in filepath (encoded member not getting initialized), which may explain why it wasn't always reproducible. Proposed fix: 2b543918994ceb2271b4589ba5022b3da922ed67 needs review.
- Project changed from Ceph to CephFS
- Category deleted (
24)
- Status changed from Fix Under Review to Resolved
Also available in: Atom
PDF