Re: No CVS working, despite of SSH connection

[Larry Jones]

schnumsel writes:
> 
> Hello Kevin, thats a good hint! Thanks a lot. Nevertheless i do not
> understand it (or not completely). i think it is - as larry assumed -
> the unionfilesystem which is causing the problem:

It is.

> > lstat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > lstat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> 
> so i guess here it is looking for the working directory

In particular, it's getting the current directory's "signature" -- the
device number and inode number.

> > openat(AT_FDCWD, "..", O_RDONLY|O_LARGEFILE) = 3

This is opening the parent directory.

> > fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

And this is getting its signature, which will be used in the next
iteration.

> everything ok. found seven entries in /home (which is correct)
> 
> > fstatat64(3, "snm", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 
> > AT_SYMLINK_NOFOLLOW) = 0
> 
> no idea what that is... guess no problem, checking for snm

This is getting the signature of "snm" in the parent directory.  It
matches the signature we're looking for, so we now know that "snm" is
the name of the current directory and we go on to the next iteration.

> > openat(3, "..", O_RDONLY|O_LARGEFILE)   = 4
> 
> going up one more level
> 
> > fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

Again, this is getting the new directory's signature for use in the next
iteration.

> > close(3)                                = 0

We're done with the previous directory, so close it.

> > getdents64(4, /* 29 entries */, 65536)  = 768
> 
> so 29 entries in "/". true.
> 
> [...]
> > fstatat64(4, "home", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 
> > AT_SYMLINK_NOFOLLOW) = 0
> [... omitted the other 28, there is a difference because why is it
> checking everything, not only "home"]

Because the signature of "home" didn't match the signature we were
looking for, but it should have.  Apparently, the "home" directory
exists in both layers of the union mount and the stat call is returning
the information for the other one rather than the one that home/snm/..
is pointing to.  Whether that's a bug in the unionfs code or you are
misusing it, I cannot say.  You will need to consult experts for your
particular operating system to determine how to proceed.  It may be
possible to avoid the problem by removing empty directories (like "home"
and "tmp") from the read-only filesystem, but it's also possible that
they will advise you to not union mount /.

-Larry Jones

Can I take an ax to school tomorrow for ... um ... show and tell? -- Calvin