Hi,
For some days, my usage of git is not as seamless as before.
I'm using git along sshfs/fuse (don't blame me for that), and each time I try to rebase one of my branch, I have a conflict when applying the third commit. Doing the same operation on a local filesystem works without any problem.
===== Part one: git =====
When I try to rebase one specific branch, git rebase failed when applying the third commit, telling me about uncommited
I've tried to do it from scratch, using git format-patch / git am but git am also abort on the third patch with the error message:
error: <path>/<filename>: does not match index
So I've tried to diagnose the problem using :
- git diff / git status : doesn't return anything.
- git ls-tree HEAD -l <path>/<filename> : returns the correct mode and file size.
- git log --raw --all --full-history -- <path>/<filename> : returns valid information matching the one retrieved above.
- git hash-object <path>/<filename> : gives the correct sha1 for the file, as recorded in the patch extracted using git format-patch and reported by git ls-tree or git log (see before)
- git diff-files : it shows a lot a file, all of them in same directory
:100644 100644 <sha1> 0000000000000000000000000000000000000000 M <path>/<filename0> :100644 100644 <sha1> 0000000000000000000000000000000000000000 M <path>/<filename1> :100644 100644 <sha1> 0000000000000000000000000000000000000000 M <path>/<filename2> :100644 100644 <sha1> 0000000000000000000000000000000000000000 M <path>/<filename3> :100644 100644 <sha1> 0000000000000000000000000000000000000000 M <path>/<filename>
BTW, there's no conflict when applying the patch manually with patch: the patch itself is fine Using git apply --index also work, but only if it's applied alone: apply each patches in series and git apply fails in the same third patch.
After diving into git source code and some debugging session, I've found that the inode number recorded in the active_cache doesn't match the one on the filesystem for <pach>/<filename> : that's why git apply --index refuse to apply the patch.
Then I tried to monitor stat() information for the file in <path> during git operations. 1) After applying the first patch, files in <path> were affected different inode number 2) Using strace, I checked that git apply didn't make anything specials to thoses files. The only thing strange git did, was trying to unlink(<path>), but this failed since the <path> directory wasn't empty.
Note: the first patch remove, change and add some files in <path> directory, while the third patch changes another file in <path> directory
As a workaround: running git diff / git diff --cached / git status between each git apply --index command seems to update the cache and allows me to apply all the patches without problem. But it's not an easy path to follow when rebasing branches.
Surprisingly, when looking at strace output, it seems that git apply, once work done, is calling lstat() for all the files under <path>, and it sees the new inodes allocated to those files, but I don't know what it is doing with those information, if it's not stored in the index.
To conclude, it was a bit hard to diagnose from git point of view.
====== Part two: sshfs / fuse ======
At this time sshfs seems to be guilty of bad behavior, breaking somes POSIX rules.
So I tried the following testcase on another computer to reproduce the problem outside of git.
Here the results:
$ mkdir dir $ touch dir/a dir/b $ stat -t dir/* dir/a 0 0 81b4 500 500 15 3 1 0 0 1297882724 1297882724 1297882724 4096 dir/b 0 0 81b4 500 500 15 4 1 0 0 1297882726 1297882726 1297882726 4096 $ rmdir dir rmdir: failed to remove `dir1': Operation not permitted $ stat -t dir/* dir/a 0 0 81b4 500 500 15 6 1 0 0 1297882724 1297882724 1297882724 4096 dir/b 0 0 81b4 500 500 15 7 1 0 0 1297882726 1297882726 1297882726 4096
One can see that inode 3 became inode 6 and inode 4 became inode 7 after the failed unlink operation on dir. Which seems to be a bit uncommon for me.
Note: on a local filesystem, rmdir failed with message rmdir: failed to remove `dir1': Directory not empty
I try to add some debug support to fuse / sshfs in order to locate more precisely the problem: (lines beginning by -/+ where added by me in libfuse, line beginning with --/++ in sshfs)
$ sshfs localhost:<export> <mount> -o sshfs_debug,debug,cache=no -d -f -s
unique: 22, opcode: FORGET (2), nodeid: 4, insize: 48, pid: 0 - forget 4 FORGET 4/1 DELETE: 4 + forget 4 unique: 23, opcode: FORGET (2), nodeid: 3, insize: 48, pid: 0 - forget 3 FORGET 3/1 DELETE: 3 + forget 3 unique: 24, opcode: RMDIR (11), nodeid: 1, insize: 44, pid: 9044 - rmdir 1 dir rmdir /dir -- rmdir(/dir) [00020] RMDIR [00020] STATUS 28bytes (0ms) ++ rmdir(/dir) = -1 unique: 24, error: -1 (Operation not permitted), outsize: 16 + rmdir 1 dir unique: 25, opcode: FORGET (2), nodeid: 2, insize: 48, pid: 0 - forget 2 FORGET 2/1 DELETE: 2 + forget 2
One can see that the reference to files under the directory are asked by the kernel to be forgotten, even if the directory is not yet removed.
This seems a bit illogical since a directory with files under it can't be removed (but FORGET could apply to file deleted but still referenced by a process).
Note: if the file is opened, the inode associated to the file name didn't change. Hopefully.
I've tried to reproduce the problem with other virtual filesystem like shm / tmpfs / devtmpfs / ramfs : no problem.
I've also tried with NFS (local), and there's no problem too (the inode numbers reported from NFS client side are the same than the server side).
So it seems this a FUSE only problem, and I haven't found exactly why.
Regards.
-- Yann Droneaud ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
