Have a perplexing bug when I try to reconcile work through the CLI for perforce in that I get a large amount of files detected and added to the changelist whenever I run the command.
This happens regardless of where my current working directory is but the files always come from there, if my working directory is outside the project's root I get a 'Path {path} is not under client's root' error and they are not added, however if my working directory is under the project root they are detected and added as missing files.
I've tried numerous different combinations of the reconcile command, explicitly stating the port, user, client etc., setting up P4Config, using relative and absolute paths, changing the working directory - but I always get these ghost files.
Has anyone come across this before? Could this be a bug with P4 itself?
Edit: I finally fixed this by reinstalling P4V so I'm assuming this was some bug either my install of perforce or any local config files that would have been reset upon reinstall. For reference this is the page that finally fixed it https://community.perforce.com/s/article/15324
This is the result of the following bug:
https://www.perforce.com/perforce/doc.current/user/relnotes.txt
Bugs fixed in 2020.1 Patch 1 (2020.1/1991450)
...
#1964794 (Job #102470) *
'p4 reconcile'/'p4 status' might report about invalid filenames
of the form '//depot/0' or '//depot/100', etc. This is fixed.
Since this was fixed in a 2020.1 patch, it can be inferred that it only affects specific 2020.1 builds (i.e. those before the patch).
To fix it, make sure you're on a client version (p4 or P4V; this is not a server-side bug) whose changelist number is higher than 1964794. No special reinstallation procedure is needed; just download the latest binary/installer from Perforce's website.
Force a reinstall of P4V to fix this, details can be found here:
https://community.perforce.com/s/article/15324
Or if that page is taken down for any reason:
SOLUTION
Forcing a reinstall using the Windows msiexec installer utility with Windows msi installer file extracted from the p4vinst64.exe file can often successfully complete a full reinstall where running the P4V exe installer such as "p4vinst64.exe" fails
If not already downloaded, obtain the appropiate Windows installer for P4V (for example "p4vinst64.exe" for 64 bit Windows platforms). Currently these can be downloaded from https://www.perforce.com/downloads/helix-visual-client-p4v
Extract the msi from p4vinst64.exe; for example to extract it to "c:\p4v", open a Windows a cmd prompt and change directory to the location where p4vinst64.exe .is located and run the following command:
p4vinst64.exe /s /b"c:\p4v" /v"/qn"
Now from c:\p4v, run the following command to force a full reinstall:
msiexec /i "p4vinst64.msi" /qn REINSTALL=ALL REINSTALLMODE=vamus /L*v log.txt
I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.
Something has gone wrong with my java set-up on my computer, obviously, but I can't figure out what it is until I get some more info.
When I try to run Eclipse, it give me an error:
Failed to load the JNI shared library "C:\Eclipse\1234\tools\jdk1.5.0_14\bin\..\jre\bin\client\jvm.dll"
I want to know how to find out what the rest of that filepath is. "\bin..\jre\" doesn't help me much. I suspect that it's 2 paths concatenated, but I'm not sure.
I've tried running Eclipse from the command line, but the error shows up only in the popup window.
Also, where does the JNI path get set, anyway?
I've looked at my JAVA_HOME environment variable, but it only contains "C:\Program Files\Java\jre7\bin".
This JNI-path-corruption... thing happened after I ran an installer -- nope, no uninstaller :(
C:\Eclipse\1234\tools\jdk1.5.0_14\bin\..\jre\bin\client\jvm.dll
I want to know how to find out what the rest of that filepath is. "\bin..\jre\" doesn't help me much. I suspect that it's 2 paths concatenated, but I'm not sure.
That is the full path. On all file systems that I've used ".." indicates the parent directory (i.e. up one directory). So the path refers to:
C:\Eclipse\1234\tools\jdk1.5.0_14\jre\bin\client\jvm.dll
As for how eclipse has decided on trying to use this path, I'm not sure.
your JAVA_HOME settings are wrong , as JAVA_HOME should point to the directory just above bin , and in the bin directory java executable files e.g. java.exe , javac.exe , appletviewer.exe must exist.
For example, if on my computer java.exe is in D:\JAVA7\bin directory my JAVA_HOME will be D:\JAVA7
When I start, Eclipse says "Workspace Cannot Be Locked"
"Could not launch the product because the associated workspace is currently in use by another Eclipse application." or “Workspace in use or cannot be created, chose a different one.”
But I know it isn't.
How do I "unlock" it?
Just delete the .lock file in the .metadata directory in your eclipse workspace directory.
Precaution - If you delete the .metadata folder all preference will be deleted.
I've seen 3 other fixes so far:
in .metadata/, rm .lock file
if #1 doesn't work, try killing the process javaw.exe etc. then rm .lock file
if #1 and #2 don't work, try rm .log file in .metadata/, and double check .plugin/.
This has always worked for me: relocate .metadata/, open and close eclipse, then overwrite .metadata back
The solution boils down to cleaning up the .metadata folder.
Go to TaskManager(Right Click in the Task Bar) and select Processess menu bar and select eclipse.exe and Click EndProcess
Another possible cause of the “Workspace in use or cannot be created, chose a different one” issue is that the real path to your workspace may have changed.
In my case, the real location of the workspace had changed, but I had used a symlink to make it look like it was in the same location. I saw errors in logs indicating that eclipse was looking at the previous "real" location, as opposed to following the symlink, and this was causing the errors.
In my case, I just moved the workspace back to its old location.
There is another case where the path to the workspace may not exist, e.g., if you have imported preferences from another workspace, then some imported workspace addresses may appear in your "open workspace" dialog; then if you didn't pay attention to those addresses, you would get the exact same error once you tried to open them.
Running eclipse in Administrator Mode fixed it for me. You can do this by [Right Click] -> Run as Administrator on the eclipse.exe from your install dir.
I was on a working environment with win7 machine having restrictive permission. I also did remove the .lock and .log files but that did not help. It can be a combination of all as well that made it work.
deleting logs and .lock didn't work but
-clean option fixed it for me.
At times, if you are on Windows, you may not see all the processes - or the culprit process in Task manager. I had to click 'Show process from all users' and there was this java.exe that I had to kill in order to get back my workspace.
Another possible case if none works is to see that there is a running Java application . may be your previous open and close has left unkilled java instances.
Do look for any java instance is running if there are two at least you need to kill one.But ,most of the time i kill any java running :) because that java is using the work space earlier and still will if don't kill it.
Change another work space in case if you want a multiple IDE to use and work on diffrent or same project , but you should import project form workspace after you open your IDE.
i was faced this issue when ever the eclipse is not closed (kill eclipse process the from task manager or computer power off), i was tried below steps, it worked for me.
1) Remove the file names start with ".fileTable" from this folder
C:\eclipse\configuration\org.eclipse.osgi.manager
2) Remove the log files like text files start with numeric names from this folder
C:\eclipse\configuration
3) Open Command prompt(cmd) navigate to this folder
C:\eclipse
type below command
eclipse clean start
For Mac Users:
It could be that another instance of eclipse is running in the background. If so, use either Force Quit eclipse or
ps -ef |grep eclipse
kill -9 pid
to all the eclipse instances, and start the new workspace
Start Eclipse with the option -Dosgi.locking=none.
I got the trick here and it works.
Don't do this unless you know nobody can work on the same file at the same time.
PLease try to end task Eclipse from taskbar. It works for me.
The answer #Boris gave is correct 99% of the time, however it can also happen if you open the workspace in an older version of Eclipse. A workspace imported into/created with Juno will throw this error when opened in Galileo.
Another all-too-common reason for this problem is if you attempt to load a directory on a drive that is no longer connected. For example, Say you program in C:\Code\Java, but occasionally work off of a flash drive, H:\Code\Java. If you do not have the drive connected it can be easy to believe you are trying to load a valid directory without noticing your typo.
Another problem is when eclipse doesn't have write access to your src folder. Change the security permission and make sure "Authenticated Users" are added with all permissions checked but Full Control & Special Permissions.
I had this error after I restarted the system (after a long time. Normally I just make it sleep).
Found out that once I mounted the drives (by clicking and opening it) where project folder is located, and relaunching eclipse, solved the issue for me.
PS: I'm an ubuntu user.
Here are a few steps to solve it the no. 4 step is works for me.
Delete .log files along .metadata folder.
Check the current user permission make sure to check the full control checkbox click apply then OK.
If you run system drive defragmentation or maintenance before you run eclipse editor sometimes original file path are not in their respective path to make sure run "previous version" time before your system maintenance of your drive where the eclipse workbench or something similar to this was saved.
This last option is works for me.
Check the drive letter of your current drive where the code editor was saved. If something unusual e.g before your maintenance your drive letter is K then after defragment or maintenance.
The drive letter is now L hence you should change the drive letter to its original one that is K.
to do this click the ff:
Open control panel
System & security
Administrative tools
Computer management
Disk management
in disk mngt choose the Drive example L
then right click > change drive letter & path > click remove > then ok, open it again then > click add and > choose your original drive letter for that drive then click ok. If you use your computer for a long period of time do restart first to refresh everything.
Choosing a "different one" is actually a pretty easy solution.
I had been running Eclipse as an administrator (sudo eclipse from the command line) because the "workspace" folder was throwing the Workspace in use or cannot be created… error (and running as administrator seemed to be the only solution that fixed it).
A coworker (working on this same issue with me) wanted to run Eclipse by clicking on an icon. So when he ran Eclipse, and the dialogue box came up with the choose your workspace, he just added a "2" to the end of "workspace".
This created a new folder: "workspace2". Eclipse ran fine with that; and I haven’t had any of the locking problems since.
It will occur when you not closed eclipse.exe correctly.
*Open Task manager->End task your eclipse->Now open eclipse.exe it will work.
Hope its help someone.
I have observed one case when eclipse when in forced quit, or Alt-f2 xkilled in linux, an attempt to immediately open eclipse shows that error. Even the metadat/.lock file is not present in that case.
However it starts working after a span of about two minutes
I don't know what's the wrong but I solved by creating a directory directly in c drive(c:\dev) instead of from my home folder (c:\users\me\dev). But I don't have to thinks about it. In my case, it is fresh eclipse unziped instance. I am not able to see .matadata folder in eclipse folder. By God grace, I solved.
The reason this was happening to me (with Photon) was easily fixed by changing an Eclipse general preference:
Window -> Preferences -> General: Uncheck: "Always run in background"
Once you make that change, whenever you shutdown Eclipse, it will no longer leave the javaw.exe process running in the background. I’m guessing this is a bug in Photon (or a bug with using the Amazon Corretto OpenJDK version of Java with Eclipse) that will one day be fixed.
I faced the same problem, but for some reasons the .lock file in workspace was not getting deleted. Even creating a new workspace was also getting locked.
So what I did was cleaning the windows temp folder, the %PREFETCH% folder and %TEMP% locations. Restart the system and then it allowed to delete the .lock file.
Maybe it will help someone.
It seems your workspace is used in Java TM, Open task manager and close eclipse.exe and java TM process.
What worked in my case was restarting the system. (ubuntu 20.04)
If anyone have come here with a STM32Cube related issue, which apparently is based on Eclipse and has the same problem, none of the above suggestions worked for me, and here is how I fixed it, for Linux, although I suppose you can find the corresponding paths in Windows as well.
In the $HOME directory, go to .eclipse/com.st.stm32cube.ide.../configuration/settings
The file org.eclipse.ui.ide.prefs contains few options including the recent workspace path, and whether it will prompt you to select a workspace at the startup. Either modify the path for RECENT_WORKSPACES, or enable SHOW_WORKSPACE_SELECTION_DIALOG.
In my case, there was a space right before the workspace's location C:\. I removed that space and it was enough :)