On Thu, 17 Feb 2011, Yann Droneaud wrote: > > On Wed, 16 Feb 2011, Yann Droneaud wrote: > >> 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. > > > > Yann, thanks for looking into this. > > > > Your findings are not surprising: unlike NFS, sshfs doesn't provide > > inode numbers and the fuse library also doesn't guarantee stable inode > > numbers by default. > > > > But why does it have such behavior when trying to rmdir() a non empty > directory ? The VFS (part of the linux kernel that implements the generic filesystem logic) clears the directory entry from the cache prior to actually trying to remove the directory. This has the effect that any children of the directory are also cleared from the cache, hence the behavior you see in rmdir. > > > Fuse version 2.8.x has a "noforget" option that should provide stable > > inode numbers, at the cost of unbounded memory use. Could you please > > try if this option fixes these issues? > > > > Yes, this option seems to fix the problem. > > I will try it for a while to see if this is stable enough for a full day > of git working. (How can I check memory usage ?) > > BTW, the [no]forget option did not appears in sshfs --help output. Oh, that's an oversight on my part. Will fix. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html