When copying/moving files (irrelvant if copying by drag'n'drop, ctrl-c ctrl-v or righ-click copy right-click paste) the xffm doesn't end this copy/move-operation. It counts only the seconds in the status-bar. I have to abort the operation (i got bored after 5 minutes staring at the increasing number of seconds ;) When I abort the operation after a few seconds, the file is copyied correctly. This phenomenon appears only on my FreeBSD-amd64 installation. An i386-Installation on the same machine doesn't show this effect. I'm using XFCE 4.2.0 installed with the FreeBSD ports-collection. Reproducible: Always Steps to Reproduce: 1. copy file 2. paste file 3. observe the status-bar Actual Results: Copy/move-Operation doesnt end Expected Results: Copy/move-Operation ends successfully after copying/moving the File.
Apparently what is happening is that xffm is unable to determine that the child process (cp in this case) has finished. So the seconds keep counting even after the operation is complete. From the code libs/tubo.c: #ifdef __FreeBSD__ /* This apparently does the bug workaround for wait failure * on FreeBSD 5.1: */ if (kill(PID,SIGCONT) == 0) return TRUE; #endif waitpid(forkO->PID, &status, WNOHANG); From this code we can see that there is a bug workaround for something similar in freeBSD 5.1. You could try to see if this bug workaround is now causing problems in freeBSD-5.3-amd64, or if a different workaround is now needed.
> #ifdef __FreeBSD__ > /* This apparently does the bug workaround for wait failure > * on FreeBSD 5.1: */ > if (kill(PID,SIGCONT) == 0) return TRUE; > #endif > waitpid(forkO->PID, &status, WNOHANG); > > From this code we can see that there is a bug workaround for something similar > in freeBSD 5.1. You could try to see if this bug workaround is now causing > problems in freeBSD-5.3-amd64, or if a different workaround is now needed. By deleting the #ifdef-block, apparently the problem has gone. Thanks a lot.
Now the question is whether the bug workaround within the #ifdef block is still necessary for non-amd64 systems running FreeBSD-5.3.
My i386 5-STABLE installation doesn't need this #ifdef-Block to work correctly.
Try using the find function with lengthy searches (needles inside haystacks) and press stop button to interrupt. No fgr sub processes should be left running nor zombies created. AFAICR, this was the problem in freebsd 5.0 through 5.2.1
i can confirm this same problem on i386 FreeBSD 5.4 with Xfce 4.2.1. i installed xfce from the packages at freebsd's ftp (ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.4-RELEASE/packages/)
I've now removed support for the bug workaround (FreeBSD <= 5.2.1) since it only seems to cause problems in >= 5.3. The best solution would be to check for the FreeBSD version and only disable in builds >= 5.3, but I don't know how to do that. The change has been committed to SVN head and will appear in xffm-4.3.3.
I'm not sure whether this will help you... but with the sysctl tool you can get this information about freebsd version. kern.osrelease: 5.4-RELEASE kern.version: FreeBSD 5.4-RELEASE #0: Tue Jul 26 21:08:32 EEST 2005 kern.osreldate: 504000
Hi, Checking for the FreeBSD Version could be done with: #if defined(__FreeBSD__) # include <osreldate.h> #endif #if defined(__FreeBSD__) && __FreeBSD_version < 503000 /* work around the bug for old versions */ #endif
The code has now been restructured and the method for determining process termination from "wait" is no longer required. This should take care of the problem. To test from svn, compile and install xffm/libtubo, xffm/libxffm and xffm/xffm-gui (xffm has been split into several different packages for upcoming release 4.3.4).
(In reply to comment #10) > The code has now been restructured and the method for determining process > termination from "wait" is no longer required. This should take care of the problem. > > To test from svn, compile and install xffm/libtubo, xffm/libxffm and > xffm/xffm-gui (xffm has been split into several different packages for upcoming > release 4.3.4). > > Assuming this is fixed in Xffm 4.3.4