FUSE plugin
===========

The FUSE plugin gives read-only access to a backup repository.
There's a lot of potential corner cases here, but for now, this
test suite concentrates on verifying that at least the basics work.

    SCENARIO Browsing backups with FUSE plugin
    ASSUMING user can use FUSE
    AND extended attributes are allowed for users
    GIVEN directory L with interesting filesystem objects
    AND a manifest of L in M
    WHEN user U backs up directory L to repository R
    AND user U FUSE mounts the repository R at F
    THEN L, restored to F/latest, matches manifest M

The FUSE view of the repository won't change while we have it mounted,
even if we make a new backup.

    GIVEN 100k of new data in directory L
    AND a manifest of L in M2
    WHEN user U backs up directory L to repository R
    THEN L, restored to F/latest, matches manifest M

However, if we read the file `F/.pid`, the FUSE plugin refreshes the
view and we can now see the new backup.

    WHEN user U reads file F/.pid
    THEN L, restored to F/latest, matches manifest M2

Clean up.

    FINALLY unmount repository F

In 2014, for Obnam 1.7, a bug was reported that the FUSE plugin would
only read the first 64 kilobytes of a file. Verify that this is no
longer a problem.

    SCENARIO restoring a big file with FUSE
    ASSUMING user can use FUSE
    GIVEN 1M of data in file L/big.dat
    AND a manifest of L in M
    WHEN user U backs up directory L to repository R
    AND user U FUSE mounts the repository R at F
    THEN L, restored to F/latest, matches manifest M
    AND big.dat in L and in mounted F compare equally
    FINALLY unmount repository F

We can only run this test if the user is in the `fuse` group. This may
be a portability concern: this works in Debian GNU/Linux, but might be
different in other Linux distros, or on non-Linux systems. (If it
doesn't work for you, please report a bug.)

We do the backup, and verify that it can be accessed correctly, by
doing a manifest of the live data before the backup, and then
against the FUSE mount, and comparing the two manifests.

    IMPLEMENTS WHEN user (\S+) FUSE mounts the repository (\S+) at (\S+)
    mkdir "$DATADIR/$MATCH_3"
    run_obnam "$MATCH_1" mount -r "$DATADIR/$MATCH_2" \
        --to "$DATADIR/$MATCH_3"

We also check a specific file by comparing it in the mount and in its
original location. We do the comparison with cmp(1) instead of the
usual way, because this triggered a bug.

    IMPLEMENTS THEN (\S+) in (\S+) and in mounted (\S+) compare equally
    cmp \
        "$DATADIR/$MATCH_2/$MATCH_1" \
        "$DATADIR/$MATCH_3/latest/$DATADIR/$MATCH_2/$MATCH_1"

If we did do the fuse mount, **always** unmount it, even when a step
failed. We do not want failed test runs to leavo mounts lying around.

    IMPLEMENTS FINALLY unmount repository (\S+)
    if [ -e "$DATADIR/$MATCH_1" ]
    then
        fusermount -u "$DATADIR/$MATCH_1"
    fi