| Age | Commit message (Collapse) | Author |
|---|
|
As a bonus you can build out-of-tree now via make -f.
It's part of the work related to issue #22.
|
|
During implementation and tests of new dump action, I've noticed that
while non-textual values in extended attributes were properly stored in
.metadata file, retrieving them from it was simply broken, i.e.
anything beyond first null byte was zeroed.
Small quantum of solace is the fact that apparently metastore users
rarely use extended attributes or at least rarely with non-textual
values, because otherwise they would surely report such crucial bug.
Let's perform simple test to show the problem:
$ mkdir -p ~/testxattr/ && cd ~/testxattr/ && touch test
$ setfattr -n user.txt -v "tekst" test
$ setfattr -n user.bin -v 0x020100ff00 test
$ getfattr -d -e hex test
# file: test
user.bin=0x020100ff00
user.txt=0x74656b7374
$ metastore -s test
$ OFFSET=$(($(grep -abo user.bin .metadata | sed 's/:.*//')+8+1+4))
$ xxd -p -l5 -s $OFFSET .metadata
020100ff00
So far everything seems fine, i.e. user.bin xattr is properly stored.
$ metastore -c test
./test: xattr
Apparently on-disk test xattrs differ from those in metadata file,
even though they should not!
Let's apply those from metadata file and show how they look on-disk.
$ metastore -a test
./test: changing metadata
./test: removing xattr user.bin
./test: adding xattr user.bin
$ getfattr -d -e hex test
# file: test
user.bin=0x0201000000
user.txt=0x74656b7374
Oh no! Extended attribute with non-textual data has been corrupted now.
But no more, because this commit fixes it!
As long as you haven't stored corrupted xattrs in metadata file, you can
still recover on-disk ones by applying them from metadata file using
fixed version of metastore.
|
|
Turn
version 2 of the License
into
only version 2 of the License is applicable
and restore the semicolon preceding it.
|
|
Wording has been changed only in Makefile, where:
Free Software
has been fixed into proper name:
Free Software Foundation, Inc.
with trailing comma separating it from address.
|
|
This removes warnings shown during build with -Wextra flag.
Signed-off-by: Przemyslaw Pawelczyk <przemoc@gmail.com>
|
|
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
