How to Fix open for write P4 ERROR? - linux

I am having difficulty getting rid if the following error:
bash-3.00$ p4 login
Enter password:
Fatal client error; disconnecting!
open for write: /home/myuserid/tmp.17236.3: No such file or directory
The file does not exist nor do I know why it ever did.
How can I clear this?
Thanks

There are a couple of environment variables that might be at play. They control the temp location that Perforce uses for intermediate files, and also the location of the tickets file that contains the login tickets. As Bryan mentioned you should run 'p4 set' and look at your Perforce-related environment.

This was a permission issue on my home directory.
Once the home directory was created correctly the issue was resolved

Right-click cmd.exe
"Run as Administrator"
try your command again

Related

Unable to create 'launch.json' file inside the '.vscode' folder ({0})

I'm on a linux machine running vscode. I am trying to do some debugging but whenever I try to select the environment configuration I get the message, "Unable to create 'launch.json' file inside the '.vscode' folder ({0})."
I suspect it could be a permissions thing but when I try to run vscode as an elevated user I am warned not to. Instead it advises that I can change the user data directory. Will this fix my problem?
After some digging, it turns out that the .vscode directory is created inside the root folder of each project added to vscode. To resolve the problem I had to create the folder manually and give permissions for vscode to write to the directory.

p4v not looking in correct root directory for workspace

I am trying to look up history for a workspace in p4v. I believe I changed the root directory at one point, and the updated root is shown in the workspace info from p4v and from command line. However, I get the following when I attempt to review history.
Path 'c:\path_to_old_root\...' is not under client's root 'c:\path_to_new_root'.
The Perforce command run is:
p4 changes -s submitted -l -m 100 c:\path_to_old_root...
Additionally, when looking at the workspace in the selectro on the left side pane it shows c:\path_to_old_root\ for the local directory.
I am unsure why it is the generating the command/determining local directory to use in the manner it is.
Not sure why this occurred, but it appears files in the .p4qt directory were not correctly updated. Based on the suggestion that deleting said directory might be helpful, I searched the directory for occurrences of the old root path and replaced them with the new root path. This appears to have corrected the problem.

Microsoft.WindowsAzure.targets "The specified path, file name,or both are too long"

I am trying to publish a project to Windows Azure but get an error in the generated Microsoft.WindowsAzure.targets file related to length of paths and file names. How can I determine which is the problematic path or filename. The error relates to the "" tag in the generated file
Thanks
Martin
Already an older post - did you check this post?
Path too long error when building a windows azure service
This might reslove your issue.
Since this was still a problem for me years later and the above doesn't apply to Azure SDK v2.8, I was able to solve it by creating a symbolic link to my projects folder. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.

Where's the "TEMP" folder for Custom Build Steps?

Visual Studio 2010, in my project I made a custom build step which renames a dll file and copies it to other folder. So, Alt+F7, Config props, Custom Build Step / General, command line:
copy /y $(TargetPath) $(TargetName).node
It didn't do anything. Then I also added
ping bat.femei.ro -n 1 -w 5000
It still didn't do anything. It simply flashed a command prompt window for a split second then the window went away. I googled as much as I could concluding that there might be a problem with the folder where the batch file is generated.
I did my best to screenshot that split second with the command prompt and after a boring F7-PrintScreen-PasteInPaint session finally I got
C:\Users\FURAT\AppData\Local\Temp\blablablablablablablablabla.exec.cmd is not recognized as internal or external...
I double checked the directory. It has Everyone permissions set to Allow both Read & Write operations. What's wrong? How do I fix this?
I was unable to find any knobs to tweak temp folder path. It's not Env and it's not in the config either.
What did work however was running VS2010 as Administrator. Now the Custom Build Step works.

SVN Error (Can't set file)

Everytime I try to commit files to SVN I got the following error.
Command Commit
Modified D:\Project\src\WebSite\SomePage.aspx.cs
Sending Content D:\Project\AKent\src\WebSite\Test\SomePage.aspx.cs
Commit succeeded, but other errors follow:
Error bumping revisions post-commit (details follow):
Can't set file 'D:\Project\AKent\src\WebSite\Test\SomePage.aspx.cs'
read-write: Access is denied.
After I get this error, SVN doesnt allow me to update or commit anything! And what is really frustrating me is that the project folder is around 2 GB and every night I download it from SVN over and over.
Please help me to fix it! I just wanna know what is wrong with my SVN. I tried reinstalling, didn't fix anything.
I had the same problem but fixed. My solution is:
1. Run Command Prompt as Administrator
2. Navigate to the target working copy
3. svn cleanup
The error
read-write: Access is denied.
indicates that svn can not access the file or can't set all attributes it needs to that file.
Now that either means you have not full access to those files or some other application has the file opened exclusively.
In the first case: make sure that your username has full access to all folders and subfolders of your working copy. Note that on Vista/Win7 it's not enough to be an admin - you have to give yourself full access to such files manually.k
In the second case: disable windows search indexer for your working copy, and exclude the working copy from being scanned by your virus scanner.
If you are sharing a svn versioned folder using samba and running into this issue when acessing it from windows machine, try:
http://tortoisesvn.net/faq.html#samba
Also add to your smb.conf file:
dos filemode = yes
copy the wrong folder (1) to another folder(2)
delete the wrong folder (1)
copy the backup(2) to (1)
Hope this approach works for you too!
I was trying to revert a file but was receiving the error listed in the OP's post. Soony's answer just about worked for me. I cannot comment or edit that answer, so I had to copy their answer and add a small step at the end. S/he deserves all the credit.
Run Command Prompt as Administrator
Navigate to the target working
copy svn cleanup
svn revert [filename]
(the revert did not work in Windows Explorer/TortoiseSVN integrated tools, I had to do it from the cmd line)

Resources