Description of problem:

A recent commit (details below) has broken the functionality of a simple fuse<->storage/posix graph (i.e., mount fuse on top of a local directory). This is obviously not a typical gluster configuration, but I think it's something we expect to work (it's helpful for debugging/hacking, at least).

Version-Release number of selected component (if applicable): 


How reproducible: 100%


Steps to Reproduce:
1. Create the following volfile:

volume test
    type storage/posix
    option directory /export/test
end-volume

2. Run glusterfs:

glusterfs --volfile=./test.vol /mnt/ --no-daemon

3. Attempt to create a file:

touch /mnt/file
  
Actual results:

touch: cannot touch `/mnt/file': Input/output error

[2012-05-18 14:10:27.083195] E [posix.c:135:posix_lookup] 0-brick: null gfid for path /file
[2012-05-18 14:10:27.083326] E [posix.c:152:posix_lookup] 0-brick: lstat on (null) failed: Success
[2012-05-18 14:10:27.083377] W [fuse-resolve.c:91:fuse_resolve_entry_cbk] 0-fuse: 00000000-0000-0000-0000-000000000000/file: failed to resolve (Success)
[2012-05-18 14:10:27.084018] E [posix.c:135:posix_lookup] 0-brick: null gfid for path /file
[2012-05-18 14:10:27.084074] E [posix.c:152:posix_lookup] 0-brick: lstat on (null) failed: Success
[2012-05-18 14:10:27.084111] W [fuse-resolve.c:91:fuse_resolve_entry_cbk] 0-fuse: 00000000-0000-0000-0000-000000000000/file: failed to resolve (Success)


Expected results: Successfully create the file.


Additional info: I bisected this behavior down to the following commit:

27fb213 fuse-resolve: consider cases where an entry should be resolved even when parent belongs to active itable.