Four of my Github repositories get an "invalid path" error when I try to commit to master on Github Desktop (Windows). They've been working for years. I have copied the folders to and from a laptop recently, but I have also done that in the past with no problems.
error: invalid path 'qbug/'
error: qbug/: cannot add to the index - missing --add option?
fatal: Unable to process path qbug/
How can I fix this, and how can I prevent it from happening in the future?
Related
Edit 1: I am using the floobits plugin (latest release), uninstalled and installed again from the package manager. I am not getting a traceback but an error window with the following error message: Unable to join workspace. CERTIFICATE_VERIFY_FAILED unable to get local issuer certificate (_ssl.c:1124).
Edit 2: I had tried the Package Control Upgrade package and Staisfy Dependencies, but that did not help fix it.
I was able to fix it (answer below).
I have been stuck on this issue for days now. When I try to connect to a floobits workspace in sublime text, I get the error message that CERTIFICATE_VERIFY_FAILED unable to get local issuer certificate (_ssl.c:1124).
I searched about this a lot but I don't know what's wrong anymore.
I started by upgrading certifi and pip itself.
Then I read somewhere that I should check if OpenSSl(and the requests library of py) and cURL can open the URL (floobits.com) since the workspace is hosted there. curl returned no errors but OpenSSL (and requests) wasn't able to verify, gave the same error.
So I downloaded the certificates from the website on opening it in chrome. I downloaded all three certificates (for the root, intermediate and the website itself), and appended them to cacert.pem inside the certifi package folder. After that, when I ran it, OpenSSL was able to open it (and the requests library too, got a 200 response code).
But, floobits still wasn't able to connect and gave the same error. I know that there is nothing wrong with floobits.com and the sublime extension since a friend can still open the workspace without problems.
Please tell me what I can do to fix this.
So I managed to 'solve' the problem by bringing Sublime back to a fresh state and then copying my files again. Answering here if anyone gets this problem.
Method:
Go to the Sublime > Preferences > Browse Packages
In this folder, copy and backup the 'User' folder to someplace else.
Delete all the folders in this location (Sublime need not be closed during this but it's best if you do close it)
Copy the backed-up 'User' folder back here (remember the location where you deleted, %AppData%\Roaming\Sublime Text 3\Packages (for Windows))
All set, you now have a fresh installation of sublime.
Sublime will start installing all packages again, wait for it to finish and resume work.
This solved the problem I was having. Unfortunately, I couldn't track down the problem.
I am trying to update my project using svn (right click on the project name -> Subversion -> Update Directory). The next error appears: "No versioned directories to update were found".
Also, when I try to checkout the project, i get the following error
Can someone please help me with this?
The error is rather generic, it basically means svn client could not connect. Could be caused by misconfigured proxy server settings, errors in servers configuration file or firewall.
Check if it works in the command line in the first place. Also, check the IDE logs, the issue could be caused by something else
I am running this error during the "DOWNLOAD_SOURCE" phase in CodeBuild:
"invalid pkt-len found"
No other information is provided. I have tried various things to rule out problems.
a) The CodeCommit repo clones successfully, and appears to be fully functional.
b) Building from an earlier revision on this CodeCommit repository that had previously built successfully now throw this error -- Fails with same error message
b) Building from a separate CodeCommit repository with a separate CodeBuild project that has previously built successfully AND has no new commits -- Fails with same error
c) A brand new CodeBuild project and CodeCommit repo -- Does not fail
d) Building the same CodeBuild job that fails, with a zip file (of the same code base) as source instead of CodeCommit, and it does not fail.
I was getting the same error in Codebuild. Turned out, I was using a URL of a sub-folder in the repository. Since it was not a proper Git repo URL, it was throwing an invalid pkt len error. I hope this helps somebody who stumbles onto the same error.
Got a response from AWS - this was an issue on their end, which they have resolved.
We maintain a Debian repository for an app and all .deb files are stored on a s3 bucket.
We wrote a script to upload the files and update the Packages.gz file. All went fine until one of the developers found deb-s3 and tried using it.
After the first package upload we started getting this error message:
W: Failed to fetch s3://s3.amazonaws.com/myapp/dists/test/main/binary-amd64/Packages Hash Sum mismatch
I've tried to restore an old version of our Packages.gz file with no success. I've searched for this error and removing the /var/lib/apt/lists/ does not work either.
What would deb-s3 do that could break our entire repo?
Looks like deb-s3 creates a Releases file under dist/test and that conflicts with Packages.gz.
Removing the Release file restored our repository back to what it was.
I'm having some strange issues with WiX on my local machine. The problem is intermittent, but after a few rebuilds of the solution, the WiX project starts throwing ICE validation errors.
If I go into my AppData\Local\Temp folder and delete all the temporary folders that contain the MSI, the solution compiles again. A short while later, the problem starts happening again. Having to keep clearing down the temp folders isn't a sustainable or satisfactory solution.
Has anyone else encountered this issue? The validation error codes seem to always be a combination of ICE30, ICE38, ICE64 and ICE91
Update:
As requested, here are the entries from the most recent failure:
error LGHT0204: ICE38: ICE Internal Error 1002. API Returned:
1615. error LGHT0204: ICE38: Error 2235: /OU.AppFramework.Includes.msi, _Profile, UPDATE Directory SET
_Profile=0 error LGHT0204: ICE64: ICE Internal Error 1001. API
Returned: 1615. error LGHT0204: ICE64: Error 2242:
OU.AppFramework.Includes.msi, _Profile, ALTER TABLE Directory ADD
_Profile SHORT TEMPORARY HOLD error LGHT0204: ICE91: ICE
Internal Error 1001. API Returned: 1615. error LGHT0204: ICE91:
Error 2242: OU.AppFramework.Includes.msi, _Profile, ALTER TABLE
Directory ADD _Profile SHORT TEMPORARY HOLD
Interestingly, this failure occurred before I left the office last night, and the solution compiled OK when I came in this morning. As it seems to centre on the temp directory where the MSI is build by WiX, could it be the build process locking the file?
Update 2:
And now we're back to over 600 errors, mostly repetition of this error:
error LGHT0204: ICE30: ICE Internal Error 100. API Returned: 1615.
error LGHT0204: ICE30: Error 2235: AppFramework.Includes.msi,
_ICE30SFN, SELECT Directory_Parent, Directory, DefaultDir, _ICE30SFN, _ICE30LFN FROM Directory WHERE
Directory.Directory=? AND Directory_Parent<>?
Update 3:
The problem still exists even after trying the suggestion by #limpan. There are a couple of warning given by light that are caused by the MSI output folder being locked when light tries to access the MSI:
Warning 549 The directory '\AppData\Local\Temp\2opu3hxf' is in use and cannot be deleted. light.exe
Try adding <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to your WiX project file.
We've had the same issue for a while, and tried various workarounds including deleting the temporary files and setting the msbuild environment variable. These all appeared to work for a while, but eventually (sometimes after a few days) the problem would come back again.
I noticed that on my machine devenv.exe was the process that was locking the files that light.exe was trying to delete. I also stumbled across an unrelated thread which mentioned this project setting to make the WiX tools run out of process. I thought it could be worth a try and it appears to have cured the problem for us (so far...)
I had this issue as well and solved it in my environment.
Short answer:
Add the environment variable MSBUILDDISABLENODEREUSE=1 and restart Visual Studio
Long answer:
There was a warning during build that I first didn't see since I was too focused on the error:
Failed to delete temporary directory: C:\Users[username]\AppData\Local\Temp\5[uniqueFolderName] light.exe
I tried to remove the folder manually, but it was in use by another process.
It turns out that a lot of MSBuild.exe processes are started during build and then not closed again.
You can read more about the reason for that and what you can do to change that behavior in Stack Overflow question msbuild.exe staying open, locking files.
This thread: it and the solution in this thread:
I hope this answer can help someone else.
For ICE30: ICE Internal Error 100. API Returned: 1615, please try this and see if it works:
Close all instances of Visual Studio (may be just the one that matters but just in case)
Go to C:\Documents and Settings\\****user id****\\Local Settings\Temp\.
Clear all the folders that look like this .. 's12qgaks'. Basically it contains the MSI files
Open the solution and recompile.
Good luck!
I too had faced same the issue. In project properties, go to Tool Settings and click Suppress ICE validation.
For me MSBUILDDISABLENODEREUSE=1 (or /nr:false on command line) did not solve the problem.
But <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> did its job done.
I had the same issue. It turned out to be my Anti Virus software (OfficeScan) It had the intermediate files created by Light.exe locked and the validation process failed. Excluding the temp folder from virus scan or turning off ICE validation is not an acceptable solution.
If anyone has a better solution. I would like to know.