 |
History
| Log In
|
|
|
|
Hi Rebekah,
I have tried to reproduce this, but so far to no avail. I wonder if you could check a couple of things for me: - the data directory Pulse is reporting on the agents > master > info tab - the pulse.data value in your $HOME/.pulse/config.properties file ($HOME may be C:\ if you run as a service) Even if I deliberately configure an extra slash in mine, it gets removed by the Java File APIs and the Perforce client ends up with a 'normal' root. Hi,
Sorry for the delay in responding. data directory /export/godemine/dev/irms/pulse/data The pulse.data= was not defined... Hi Jason,
I'm having trouble with this still. It is adding the extra backslash after D (D:\\pulse_data) in the pulse workspace and that is causing a bug in one of the programs. I've deleted the extra slash from the pulse workspace and triggered the project. I see the D:\\pulse_data from the beginning, but the bug doesn't happen the first time. It happens always the second time I trigger it, and thereafter. Anyway, after I trigger the project, the D:\\ shows up in the workspace again. It only does it on our Win32 machine, not the Win64. > I've made sure all the environmental variables are the same between these machines. > I've checked the config.properties files for them both machines. They are identical. Both are in: C:\Documents and Settings\irms\.pulse-agent Both say "pulse.data=D:\pulse_data". > The pulse paths under Pulse > Agents > Win32 > Info is without a backslash : home directory: .. data directory: D:pulse_data (no backslash at all...?) But for Win64, data directory is D:\pulse_data I stopped and restarted the pulse agent on win32 and it actually said it had an error stopping. But I was able to restart it. I would appreciate any advice you can give. Thanks!!! Hi Rebaka,
Thanks for the information. Unfortunately I still cannot reproduce this locally. However, as the symptoms seem relatively clear, I have implemented a likely fix by ensuring the path used for the Perforce root is normalised first. As I can't test I can't guarantee this fix will work, so if not please let me know and we can reopen this issue. Implemented in change 5138, merged to trunk in change 5139. Hi guys,
Now, I have upgraded to Pulse 2.0.33. Very nice, by the way! It is cool with the agents info tab because I can see the data directory directly. It now says: data directory D:\\pulse_data The config.properties includes this: pulse.data=D:\pulse_data I changed it to say this to see what would happen: pulse.data=C:\pulse_data Then restarted the service and refreshed the info tab. It then said: data directory C:\Program Files (x86)\Zutubi\Pulse Agent\bin\pulse_data (only one slash) I then changed the config file to: pulse.data=D:pulse_data Restarted service and refreshed info tab: data directory D:\\pulse_data (still 2 slashes...) It is like this on all 3 of our Windows platforms. Do you have any more ideas? The only variables we are using are: PULSE_HOME: C:\Program Files (x86)\Zutubi\Pulse Agent So, I changed Changed it back Hi Rebeka,
The correct setting in the config file should be: pulse.data=D\:\\pulse_data I'm guessing that setting it to c:\pulse_data leads to a value in pulse of c:pulse_data and this is added to the working directory of C:\Program Files (x86)\Zutubi\Pulse Agent\bin to get C:\Program Files (x86)\Zutubi\Pulse Agent\bin\pulse_data. Perhaps with D:pulse_data, because it is a different file system to the working directory, Windows is adding the \\, but I'm not sure. It is also key to make sure that Pulse is using the config file you expect. Notice that the agent info tab also now tells you both the user home directory it is picking up and the config file it is picking up. You may well have double checked this already, and it seems your edits are taking some effect, but it's best to keep an eye on this when things seem strange just to be sure. I changed the config files and am not seeing this problem any more!!!! Thank you!!
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
4
Extra backslash (\) in Root path for pulse-created workspaces in Perforce
Thanks for the report. I will look into the cause of this, it should be fairly easily fixed.