Patrick Shirkey <[EMAIL PROTECTED]> writes: > Hi Scott, > > Thanks for your in depth analysis. It seems that the culprit is: > > .synce/scripts/dccm.sh > > If I remove the dccm.sh script from the path I get the same result for > ppp0. Putting it back allows ppp0 to stay up. > > Here's the script: > > ++++++++++++++++++++++++++++++++++++++ > more .synce/scripts/dccm.sh > #!/bin/sh > > case "$1" in > > connect) > ;; > > disconnect) > ;; > > start|stop) > raki=`dcop | grep raki` > dcop $raki Raki "dccmNotification(QString)" $1 > 2> /dev/null > /dev/null > ;; > > install) > ;; > > uninstall) > ;; > > *) > echo "Help!" > ;; > esac > ++++++++++++++++++++++++++++++++++++++
That's interesting. It seems to imply that your device requires Raki to be running to stay up, but I don't know why that would be; I certainly didn't use Raki when I was syncing multiple PDAs. Maybe it's a configuration option somewhere? Maybe it would be useful to redirect output to a log file to see what's going on here? It's also strange that it makes a difference to call "dccm.sh connect", which for your script doesn't seem to actually do anything I also don't see how it could be telling Raki which device to configure ($1 looks like it contains "connect"), so it would make sense if it was configuring active_connection, and so never does anything with the second PDA. Are there logs or configuration options for Raki that might be helpful? Maybe it would be useful to try shutting down Raki and see if anything different happens? Or maybe try compiling without "--enable-desktop-integration"? and see if that helps? I'm really grasping at straws here. I suspect this is a feature that has changed since last time I used synce. I see in vdccm.cpp where it's running the start scripts, but I don't see any documentation for exactly what they do or what behavior they change. Maybe somebody with more recent knowledge of synce and Raki could step in here with an explanation of what might be going on? The other thing that's odd is that vdccm seems to be treating the two devices differently, and I don't know why that would be. The first device gets writeConnectionFile called, and also "dccm.sh connect", but the second device gets neither: > ppp0 Connects here: > > [bool WindowsCEDevice::handleInfoMessage(uint32_t):93] this is an > information message > [bool ConnectionFileManager::_writeConnectionFile(std::string, const > WindowsCEDeviceBase*):117] Writing > client-file: /home/patrick/.synce/192.168.131.129 > [bool ConnectionFileManager::_writeConnectionFile(std::string, const > WindowsCEDeviceBase*):117] Writing > client-file: /home/patrick/.synce/active_connection > [static void Utils::runScripts(std::string, std::string):230] Running > script: /home/patrick/.synce/scripts/dccm.sh connect > [void DeviceManager::addConnectedDevice(WindowsCEDeviceBase*):85] Device > connected: 192.168.131.129 > . > . > . > > ppp1 Connects here: > > [bool WindowsCEDevice::handleEvent():188] this is a ping reply > [bool WindowsCEDevice::handleEvent():184] Header: 305419896 > [bool WindowsCEDevice::handleEvent():188] this is a ping reply > [bool WindowsCEDevice::handleEvent():184] Header: 0 > [bool WindowsCEDevice::handleEvent():186] initialization package > [bool WindowsCEDevice::handleEvent():184] Header: 100 > [bool WindowsCEDevice::handleInfoMessage(uint32_t):93] this is an > information message > [virtual void WindowsCEDevice::disconnect():67] Disconnect > [bool WindowsCEDevice::handleEvent():184] Header: 305419896 > [bool WindowsCEDevice::handleEvent():188] this is a ping reply > [bool WindowsCEDevice::handleEvent():184] Header: 305419896 When I ran into weirdness like this, I eventually ended up stepping into dccm with a debugger. Maybe you'll have to resort to that, too. Good luck! ----Scott. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
