|
Quoting Todd A. Jacobs, https://bugs.launchpad.net/bugs/937306:
DATA LOSS WARNING: Using metastore in its current condition can lead to
loss of metadata. See below for details.
First of all, metastore provides confusing and useless feedback to the
user when storing extended attributes without defined values. To
consistently re-create this problem:
$ touch foo
$ setfattr -n user.bar foo
$ metastore -s foo
Failed to write to file: Success
$ echo $?
1
The error message and exit status imply the operation has failed, but it
has not--at least, not completely. You can see that metastore *appears*
to have succeeded as follows:
$ rm foo
$ touch foo
$ metastore -a foo
./foo: changing metadata
./foo: adding xattr user.bar
$ echo $?
0
$ getfattr -d foo
# file: foo
user.bar
So, the .metadata file seems to contains all the correct information,
but it provides this contradictory and cryptic error message to the user
on save. However, the .metadata file *is* actually broken, but you only
see it when saving multiple extended attributes where at least one of
them has no defined value.
$ rm foo; rm .metadata
$ touch foo
$ setfattr -n user.bar foo
$ setfattr -n user.baz -v quux foo
$ getfattr -d foo
# file: foo
user.bar
user.baz="quux"
$ metastore -s foo
Failed to write to file: Success
$ echo $?
1
$ rm foo
$ touch foo
$ metastore -a
Attempt to read beyond end of file, corrupt file?
$ echo $?
1
So, there are really two things that need fixing:
1. The incredibly cryptic error message on save.
What is the actual error condition it is trying to report?
2. The proper handling of extended attributes without values.
Signed-off-by: Przemyslaw Pawelczyk <przemoc@gmail.com>
|
