Summary: | dev-vcs/cvs has broken gnulib getcwd.c - cvs [xxx aborted]: cannot get working directory: Permission denied | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Fröhlich <bornland> |
Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | andy.dalton, bornland, bugs.gentoo.org, danj, dieter.edinger, fcla.marktplaats, grimmlin, martin, matteo, nuitari, pluttero, StormByte, vapier |
Priority: | Normal | ||
Version: | 2006.0 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
testscript with cvs-1.11.21
testscript with cvs-1.12.12-r3 testscript with cvs-1.12.12-r3 new testscript with cvs-1.12.12-r3 new testscript with cvs-1.12.12-r3 new testscript with cvs-1.11.21 new Patch that fixes the problem Patch to fix cvs' internal getcwd |
Description
Thomas Fröhlich
2006-04-18 04:07:43 UTC
Does cvs-1.12.12* work on your gentoo box? What CVS version is the server using? Are your /tmp permissions correct? (In reply to comment #1) > Does cvs-1.12.12* work on your gentoo box? no 1.12.12* version! > What CVS version is the server using? 1.11.14, but i think this is not the problem, I couldn't also check out projects from sourceforge and others > Are your /tmp permissions correct? i think so! > ll /tmp/ total 18 -rw-r--r-- 1 root root 12 Apr 13 13:25 cfg srwxr-xr-x 1 root root 0 Jan 20 11:39 conftest12852 srwxr-xr-x 1 root root 0 Apr 4 09:50 conftest3243 drwx------ 2 froehlich froehlich 48 Apr 12 16:20 froehlich drwx------ 2 froehlich users 1400 Apr 18 18:19 kde-froehlich drwx------ 2 root root 48 Feb 1 10:19 kde-root drwx------ 3 froehlich froehlich 520 Apr 18 10:26 ksocket-froehlich -rw-r--r-- 1 root root 153 Apr 5 13:09 profile.CapL8B.config -rw-r--r-- 1 root root 153 Apr 6 10:26 profile.YzInle.config -rw-r--r-- 1 root root 153 Apr 5 13:29 profile.ySXh9V.config Try cvs-1.12.12-r3. What's the output of 'ls -la /tmp' (the extra lines that aren't in ll are important). (In reply to comment #3) > Try cvs-1.12.12-r3. > > What's the output of 'ls -la /tmp' (the extra lines that aren't in ll are > important). ok, I install cvs-1.12.12-r3 again, but it don't work, the same errors... $ ls -la /tmp: total 23 drwxrwxrwt 9 root root 520 Apr 21 08:23 . d-wxr----t 21 root root 520 Apr 21 2006 .. drwxrwxrwt 2 root root 112 Apr 21 08:06 .ICE-unix -r--r--r-- 1 root root 11 Apr 21 08:01 .X0-lock drwxrwxrwt 2 root root 72 Apr 21 08:01 .X11-unix drwxr-xr-x 2 root root 48 Jan 10 2000 .initrd -rw-r--r-- 1 root root 0 Jul 30 2005 .keep -rw-r--r-- 1 root root 12 Apr 13 13:25 cfg srwxr-xr-x 1 root root 0 Jan 20 11:39 conftest12852 srwxr-xr-x 1 root root 0 Apr 4 09:50 conftest3243 drwx------ 2 froehlich froehlich 48 Apr 12 16:20 froehlich drwx------ 2 froehlich users 1400 Apr 21 08:06 kde-froehlich drwx------ 2 root root 48 Feb 1 10:19 kde-root drwx------ 3 froehlich froehlich 520 Apr 21 08:06 ksocket-froehlich -rw-r--r-- 1 root root 153 Apr 5 13:09 profile.CapL8B.config -rw-r--r-- 1 root root 153 Apr 6 10:26 profile.YzInle.config -rw-r--r-- 1 root root 153 Apr 5 13:29 profile.ySXh9V.config Ok, let's do a full test run then. Please include the entire output (both stdout and stderr) from the following === start of script #!/bin/sh mkdir /tmp/test cd /tmp/test echo 'Empty password, press enter.' strace -ff cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/phpmyadmin login strace -ff cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/phpmyadmin co -P CVSROOT === end of script Put the stuff between the === dividers into a file, and run it as your regular user, like this: /path/to/testscript.sh 1>/tmp/testlog 2>&1 then upload the testlog file to here. Created attachment 85321 [details]
testscript with cvs-1.11.21
testscript with cvs-1.11.21, there it works!
Created attachment 85324 [details]
testscript with cvs-1.12.12-r3
testscript with cvs-1.12.12-r3, there it doesn't work :(
Created attachment 85338 [details]
testscript with cvs-1.12.12-r3 new
A mistake at the script :(
Created attachment 85339 [details]
testscript with cvs-1.12.12-r3 new
A mistake at the script :(
Created attachment 85340 [details]
testscript with cvs-1.12.12-r3 new
A mistake at the script :(
Created attachment 85341 [details]
testscript with cvs-1.11.21 new
mistake in testscript, sorry!!!
I am having the same issue as the OP, but on amd64. Server: dev-util/cvs-1.12.12-r3 USE="crypt nls pam server -doc -emacs -kerberos" Client: dev-util/cvs-1.12.12-r3 USE="crypt nls pam -doc -emacs -kerberos -server" From the strace I did I find these interesting lines on the pserver side (not the client!) lstat("/proc/self/fd/3/cvs-serv27711", 0x7fffffafa4e0) = -1 EACCES (Permission denied) write(8, "cvs [checkout aborted]: could no"..., 75) = 75 The mkdir/chmod in tmp is successful as per: mkdir("/tmp", 0777) = -1 EEXIST (File exists) mkdir("/tmp/cvs-serv23041", 0777) = 0 chmod("/tmp/cvs-serv23041", 0700) = 0 chdir("/tmp/cvs-serv23041") = 0 Downgrading the client to 1.11.21 did not work. Downgrading the server to 1.11.21 worked. A 1.12.12-r3 client works with the server downgrade. In my strace, the only /proc access with 1.11.21 is: open("/proc/sys/kernel/ngroups_max", O_RDONLY) = 3 Note that for people downgrading the server to 1.11.21 from 1.12.12 you will need to check out CVSROOT, comment out the line: #UseNewInfoFmtStrings=yes in the config file, then check in the updated config. This looks like a glibc bug to me... open("..", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=624, ...}) = 0 fstat64(3, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=624, ...}) = 0 fcntl64(3, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 mmap2(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dc8000 getdents64(3, /* 20 entries */, 131072) = 704 lstat64("/proc/self/fd/3/test", {st_mode=S_IFDIR|0755, st_size=48, ...}) = 0 open("/proc/self/fd/3/..", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied) munmap(0xb7dc8000, 135168) = 0 close(3) = 0 write(2, "cvs [login aborted]: cannot get "..., 69cvs [login aborted]: cannot get working directory: Permission denied ) = 69 Thomas: could you please modify the testscript, so that the strace calls include '-s 65535', and then run the test again, capturing the output. nuitari: please include your emerge --info output, and run the testscript I provided, modified as above. I'm getting a "no route to host" for the test script, I'll wait until sf gets back online. Here is the emerge --info Portage 2.1_rc1-r4 (default-linux/amd64/2005.1, gcc-3.4.6, glibc-2.4-r3, 2.6.16-gentoo-r4 x86_64) ================================================================= System uname: 2.6.16-gentoo-r4 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.12.0_pre19 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-lang/python: 2.2.3-r5, 2.3.5, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/fax /usr/share/X11/xkb /usr/share/config /var/bind /var/qmail/control /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distcc distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X alsa apache2 avi berkdb bitmap-fonts bzip2 cli crypt cups dlloader dri dv dvd dvdr eds emboss encode foomaticdb fortran gif gnome gpm gstreamer gtk gtk2 imlib isdnlog jpeg kde kdeenablefinal lzw lzw-tiff matroska mp3 mpeg ncurses nls nptl nptlonly ogg oggvorbis opengl pam pcre pdflib perl png ppds pppd python qt quicktime readline reflection sdl session spell spl ssl svg tcpd tiff truetype-fonts type1-fonts usb vorbis xinerama xorg xpm xv xvid zlib elibc_glibc input_devices_evdev input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_nvidia video_cards_v4l" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS oops, they changed their CVS structure recently. The new hosts are $PROJECTNAME.cvs.sourceforge.net so phpmyadmin.cvs.sourceforge.net for the testcase. Also, if either of you can try it safely, could you please try glibc-2.3? Server 1.12.12-r3 works with glibc-2.3.6-r2 Aurora var # emerge --info Portage 2.1_pre7-r5 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.3.6-r2, 2.6.16-gentoo-r1 i686) ================================================================= System uname: 2.6.16-gentoo-r1 i686 Pentium III (Katmai) Gentoo Base System version 1.12.0_pre17 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] dev-lang/python: 2.3.5, 2.4.2-r1 dev-python/pycrypto: 2.0.1-r4 dev-util/ccache: 2.4 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/bind /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distcc metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com/ http://adelie.polymtl.ca/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.ca.gentoo.org/gentoo-portage" USE="x86 X a52 aalib alsa apache2 apm avi bcmath berkdb bitmap-fonts bzlib cli cpdflib crypt cups curl dba dbase dga divx4linux dri dv dvd eds emboss encode esd fame flac flash foomaticdb fortran freetype ftp gd gd-external gdbm gif gnome gpm gstreamer gtk gtk2 iconv imap imlib innodb isdnlog jpeg justify kde libcaca libg++ libwww live lzo lzw-tiff mad mailwrapper matroska matrox mcal md5sum mhash mikmod mime ming mjpeg mmap mmx mng motif moznocompose moznoirc mp3 mpeg mysql ncurses nls nptl ogg opengl oss pam pcntl pcre pdflib perl png posix postgres ppds pppd python qt quicktime readline real reflection rtc samba sdl server session sharedmem sockets spell spl sse ssl sysvipc tcpd theora tiff tokenizer truetype truetype-fonts type1-fonts udev vorbis xanim xml xmlrpc xmms xorg xpm xv xvid zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY toolchain: Some glibc change in getcwd between 2.3.6 and 2.4 has broken the feature series of CVS (1.12.*). Namely, getcwd does things with /proc/self/fd/%d/%s that return EACCESS. yeah i highly doubt it much more likely the getcwd() implementation that cvs is bundling into itself via gnulib is broken if getcwd() were broken in glibc-2.4, a hell of a lot more things would be broken than just cvs try replacing lib/getcwd.c in cvs tarball with the latest one from gnulib vapier, ok, I inspected gnulib's getcwd.c for changes - the only bits NOT in CVS's copy are: a fix for Solaris AT_FDCWD, a renaming of path* variables to be dir*, and some other cleanups that would run after the error we're hitting. I did however trace down what is different between glibc-2.4 and glibc-2.3. Namely glibc-2.4 has AT_FDCWD, and hits the first part of this structure, while glibc-2.3 doesn't, and avoids the open call, using lstat instead. #ifdef AT_FDCWD fd = openat (fd, "..", O_RDONLY); if (fd < 0) goto lose; fd_needs_closing = true; parent_status = fstat (fd, &st); #else dotlist[dotlen++] = '.'; dotlist[dotlen++] = '.'; dotlist[dotlen] = '\0'; parent_status = __lstat (dotlist, &st); #endif *** Bug 133963 has been marked as a duplicate of this bug. *** *** Bug 146288 has been marked as a duplicate of this bug. *** openat is supposed to be manipulating paths via /proc/self/fd/#/.... as linux will handle the proper links back to the actual filesystem paths glibc-2.5 is in portage now ... vapier: unless glibc-2.5 is likely to be stable soon, that isn't really a solution. could I undefine AT_FDCWD maybe as a workaround for this bug? i meant glibc-2.5 is in portage so perhaps you should try upgrading and see if that fixes things ... if it does, we can look at backporting as for your question, no (In reply to comment #25) > i meant glibc-2.5 is in portage so perhaps you should try upgrading and see if > that fixes things ... if it does, we can look at backporting > > as for your question, no > I wanted to testit (glibc2.5 and cvs) but when I emerge glibc, there is no 2.5, even if I try with "~amd64".. (In reply to comment #26) > (In reply to comment #25) > > i meant glibc-2.5 is in portage so perhaps you should try upgrading and see if > > that fixes things ... if it does, we can look at backporting > > > > as for your question, no > > > > I wanted to testit (glibc2.5 and cvs) but when I emerge glibc, there is no 2.5, > even if I try with "~amd64".. > I have the same problem here with cvs-1.12.12-r2 and glibc-2.5. emerge --info: Portage 2.1.1 (default-linux/x86/2006.1, gcc-3.4.6, glibc-2.5-r0, 2.6.16-gentoo-r13 i686) ================================================================= System uname: 2.6.16-gentoo-r13 i686 Intel(R) Pentium(R) 4 CPU 3.40GHz Gentoo Base System version 1.12.5 Last Sync: Sun, 29 Oct 2006 14:00:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -mtune=pentium3 -pipe -ffast-math -fforce-addr -fomit-frame-pointer -mno-tls-direct-seg-refs" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium3 -mtune=pentium3 -pipe -ffast-math -fforce-addr -fomit-frame-pointer -mno-tls-direct-seg-refs -fpermissive" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distcc distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mir.zyrianes.net/gentoo-distfiles/ http://mir.zyrianes.net/gentoo-distfiles/ http://gentoo.mirror.icd.hu/" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/gentoo-de /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 a52 alsa apache2 berkdb bigpatch bitmap-fonts child-protection cjk cli cracklib crypt cups directfb divx4linux dlloader dri dvb dvd dxr3 dxr3-audio-denoise elibc_glibc fame foomaticdb fortran freetype gdbm gpm iconv input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog jumpplay kde kernel_linux libg++ linguas_de lirc mjpeg mmx mplayer ncurses nls nptl nptlonly nvidia pam pcre perl pp_libavcodec ppds pppd python rdesktop readline reflection samba sdl session setup-plugin slang spl sse ssl submenu tcpd truetype-fonts type1-fonts udev unicode usb userland_GNU userlocales v4l v4l2 vdr vdr-net vdrkeys vfat video_cards_fbdev video_cards_i810 video_cards_i830 video_cards_nv video_cards_nvidia video_cards_v4l video_cards_vga video_cards_vmware xorg xv xvid yaepg zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS *** Bug 149782 has been marked as a duplicate of this bug. *** Created attachment 102977 [details, diff]
Patch that fixes the problem
This patch should fix the problem by replacing "getcwd (NULL, 0)" with "get_current_dir_name()", wich does the same thing, but doesn't seem to trigger the problem.
(In reply to comment #25) > i meant glibc-2.5 is in portage so perhaps you should try upgrading and see if > that fixes things ... if it does, we can look at backporting > > as for your question, no > I emerged glibc 2.5, recompiling kernel, cvs and cvsd, but the problem is still there (amd64). Could someone try this patch and even if works including in a version bump of cvsd? (In reply to comment #31) > Could someone try this patch and even if works including in a version bump of > cvsd? Seems to work fine for me, just remember that if you're running cvsd, you need to rebuild your root after you apply the patch and recompile cvs; otherwise, the binary in the cvsd won't contain the updated version and you'll probably have all sorts of problems. (In reply to comment #31) > Could someone try this patch and even if works including in a version bump of > cvsd? > I can also affirm that this patch works. Thank you. On a side note, I applied this patch to cvs-1.12.12-r2 on an amd64 machine using the stable portage tree with glibc version 2.4 installed. Created attachment 108317 [details, diff]
Patch to fix cvs' internal getcwd
Although the previous patch should work on most systems, this does not appear to be the cleanest solution for all systems: In fact, cvs intentionally provides its own variant of getcwd(), because apparently on some systems the systems' getcwd() might fail in some occasions.
However, the getcwd() function of cvs also has a problem (see below), so probably the cleanest solution would be to *always* try the systems' getcwd() function and only use the internal function if the other fails - currently, the cvs-internal function is preferred if the system provides AT_FDCWD (which is the case on glibc systems). So, my first suggestion is to prefer the system's getcwd() even if AT_FDWCD is provided by the system.
One problem of cvs internal getcwd() function occurs reproducible in directories which are subdirectories of a unionfs-mounted filesystem.
For example, after
mount -t unionfs -o dirs=/usr/portage/distfiles unionfs /root/tmp
the cvs getcwd() function will fail in /root/tmp/cvs-src
The reason is that the directory stream of /root/tmp gives a different inode number for the subdirectory cvs-src than an stat() of /root/tmp/cvs-src - only the latter is actually the correct inode number. However, to speed up things (i.e. to save the usage of stat()) cvs internal getcwd() function "believes" the former inode number so that it will never find the actual match. So, my second suggestion is - if the cvs-internal getcwd() function should be used - to never rely on the directory stream's inode (even if it is provided by most systems). This only slows down things slightly, but works much more reliable.
The attached patch fixes both problems. Maybe these two problems should be reported upstream - they certainly fix a problem (at least that with unionfs, I do not know whether it solves the other poster's problems) and should not cause any incompatibilities except for a very mild slowdown of the internal getcwd() on some systems.
This bug still seems to exist. Is the attached patch supposed to be in portage? Thanks! please retry with 1.12.12-r12 |