Fix false error when writing zero-length records.
commitf75ca58c96bba3f4d7294aec031bd9300f278e9f
authorZak Wilcox <zakwilcox+ankigithub@gmail.com>
Tue, 29 May 2012 12:09:22 +0000 (29 14:09 +0200)
committerPrzemyslaw Pawelczyk <przemoc@gmail.com>
Thu, 7 Jun 2012 18:41:17 +0000 (7 20:41 +0200)
treec14c009143837e0fd09d8eeedb81a6626f61e0c2
parent47fa5ae63e53c08d3c4c760f055378abc0bad091
Fix false error when writing zero-length records.

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>
utils.c