Accessing lvm works only when the resource is acquired?
Yes,
needs to be acquired with SANLK_ACQUIRE_LVB flag (added lvb=True
for this in patch 1)
Nice test, but it shows that get_lvb is *decoding* the data on
output,
which is wrong. The API should accept and return the same type.
In the current form, if I try to set_lvb() with unicode value encoded
in another encoding, like:
>>> "\u05d0".encode("cp1255")
b'\xe0'
When reading the python bindings will try to decode using "utf-8"
and:
>>> b'\xe0'.decode("utf-8")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position
0: unexpected end of data
The issue is probably using the wrong format string when
building the return value.
Thanks, it was indeed wrong, used 's' instead of
'y'
Other issues that should be tested:
- Handling of too long input - the input should not be truncated silently but
but fail the call.
ack, sanlock returns E2BIG when it's larger than the
sector size, will
add a test
- Handling of null bytes in the lvm block - is this supported by
sanlock or
it treats lvm as a null terminated string?
ack, it terminates the string, will
add a test
I did not have time yet to review the other patches. The user facing
API
makes sense except the decoding issue.
Nir