just tried to create a snapshot of one of my projects. It didn't work, and Xcode did throw the following error at me: "Unable to create a snapshot. fatal: You don't exist. Go away!"
Source control commit doesn't work either. Ok, obviously there's something wrong with my local repository. I don't have the slightest idea, what that could possibly be, though. I have not committed in quite a while, but except some updates to Xcode itself, nothing major happened to the project folder, as far as I can remember.
So, what can I do about it? Is it possible to deactivate source control for that project and then start over again with source control with the projects current status? I don't need the previous versions anymore, so that doesn't need to be taken care of.
Thank you!
Looking into the git source code, this error message is generated only if
pw = getpwuid(getuid());
fails.
It indicates that the system wasn't able to find an entry for your user account in /etc/passwd or equivalent.
This can happen if your account is removed (via deluser, userdel, or something else) while you're logged in, or if you don't have read permissions on /etc/passwd (the latter should never happen).
Try the following commands at a terminal prompt:
whoami
id
ls -l /etc/passwd
grep "^${USER}:" /etc/passwd
According to the git documentation, this is the meaning of your particular error:
You don't exist. Go away!
The passwd(5) gecos field couldn't be read
This typically means the system doesn't know who you are (you'll see this sort of error on a Linux system if you delete someone's user account while they're still logged in). Is everything else working? That is, can you log out and log back in without a problem? Do other terminal commands operate correctly? What about the id command?
Can you interact with your repository on the command line? What happens if you cd into the directory and try something like git status?
WendiKidd's solution of just starting from scratch is probably the simplest thing to do, assuming it works, but you'll lose any change history already associated with your project.
I had this issue with git and running
dscacheutil -flushcache
in the terminal fixed it.
I would suggest creating a new project entirely, copying your code etc. files out of the old project, and simply migrating over into a new one (which you could then recommit to another source control directory). That seems like the easiest solution; this is a very odd error, and I've come across things in the past that are either unfixable or would take more effort to fix than taking 10-15 minutes to just set up a new project.
So that's what I'd recommend--hopefully that will fix your problem, and whatever xcode is mad at is in some hidden file or the .xcodeproj itself, and not in the files you'd need to migrate over.
Related
I'm trying to have the installer [NSIS] deleted after my electron app is installed on a device, so that the user needn't do so
Is there a possible way to achieve this
So I would not really recommend it but you could try to use the Delete function, specify your installer-file and set the /REBOOTOK Flag.
The code would look something like this:
Delete path\myInstaller.exe /REBOOTOK
This Flag tries to Delete the File right away and if it fails, wich it will since the installer is running, it will delete it after a reboot.
Just keep in mind that you would have to reboot your computer after the installation or the file will not be deleted.
Let me know if this solved your problem.
I saw some previous posted questions and their possible answers like Error:Could not read cache value from '/Users/gsp/.gradle/daemon/2.10/registry.bin' but even after deleting the folder 4.8 and rebuild and sync still getting the same error, I don't know what else the problem could be. any hint for help is appreciated. My error is could not write not could not read not even sure if deleting the version folder was a solution in the first place.
Just in case anyone have the same issue, I found out the problem was I can't write on the bldadm, I just have to fill it up which I don't have the right to do, then after discussing the issue with one of our cloud engineers they said The home dir needs to be increased, and they did which solved the issue,
There is another option.
you can delete the daemon directory that under .gradle (in my case I changed her name).
this is how it work for me.
I feel terrible about that I can't solved that alone.
I have an icinga 2.6 installed, 1 master, multiple "slave". One of our server is going to be offline for a longer time so I want to disable/remove the node.
I tried "icinga2 node remove", but I get "deprecated read changelog" error. I read the changelog, but I really can't understand why I need to reverse engineer such an easy functionality across the half internet and read already more ticket then I want...
Still no solution. I tried deleting files from the repository.d but 0 success.
Any help would be good, and some word in the official docs would be nice too :D
I'm not really sure if this is the answer you'll be looking for, but I'm giving it a shot anyways as I'm in the same boat as you are.
The only alternative I've found thus far is installing and setting up the module 'Director' on Icinga Web 2. The process is, as everything else with Icinga, poorly documented but it'll get you there. Please see here for instructions: https://www.icinga.com/docs/director/latest/doc/02-Installation/
Once installed, the module needs to be configured and old hosts may be imported. That's where it ended for me: what was documented didn't work and the error messages are probably only logical to the one that wrote them.
I've given up and am looking for a replacement to Icinga2 right now. While I liked it at the start, though it was complicated, they've now gone above and beyond creating a tool that is simply so difficult to work with that many won't.
I have 2.6 installed and needed to remove a node as well.
I know you tried to remove files and that didn't work for you - but it worked for me - so just documenting the process here in case it helps someone else.
I was able to remove the node manually by removing all files and directories related to the node in repository.d, specially in directories:
/etc/icinga2/repository.d/endpoints
/etc/icinga2/repository.d/hosts
/etc/icinga2/repository.d/zones
Note that in /etc/icinga2/repository.d/hosts there should be a subdirectory related to the node you are trying to remove - which also needs to be removed.
Once all are removed (recommend just moving to another location outside of /etc/icinga2 in case you need to revert), restart the icinga2 process.
At this point my icinga2 instance restarted successfully and the node was not showing up anymore.
Well the you need to do the next:
Execute: icinga2 node remove 'PC-name'
Will appear: deprecated read changelog
Then execute: icinga2 node update-config
And the last step: service icinga2 restart
Be happy, the node disappear
I have a rails app that contains a simple piece of code to create a directory if one does not exist.
FileUtils.mkpath(self.webapp_dir) unless File.exists?(self.webapp_dir)
This behaves as expected on my development workstation (OS X 10.9), but I'm getting errors when deployed to other environments (Red Hat 4.4.6-3).
In my rails console, I ran the following:
FileUtils.mkpath('/path/to/my/project/public/web_apps/1')
Note that on first run, 'public/web_apps/' exists, but '1' does not. This succeeds. I can run it again with the whole path already existing, and it succeeds without error every time.
Now, I try to run the same code in the rails console in the production environment. Again, 'public/web_apps/' already exists, but '1' does not. In this case I get an error.
FileUtils.mkpath('/path/to/my/project/public/web_apps/1')
--> Errno::EEXIST: File exists - /path/to/my/project/public/web_apps
Does anyone know why this behaves differently between the two machines, and what I can do about it? I suppose I could go through and check each directory in the path and create it only if it doesn't exist, but that's what I would have already expected mkpath to do.
I've found other differences between how other functions that interact with the file system behave (like how File.size does not immediately report the correct value after a file write unless you open it first). I haven't been able to find any mention of these differences in behavior in any documentation or other SO posts though, and I seem to keep stumbling upon them which is getting a little frustrating now. Is this a known thing, and how do other apps account for this?
This was actually all due to a broken sym link =(.
So web_apps was actually a sym link to a shared directory that did not exist on our servers. On my dev machine it did exist. This was not horribly obvious due to the "File exists" error.
Our deployment scripts were building the sym links without first checking if that directory actually existed. Bah.
This looks to be a permission issue, the directories are created if they DON'T exist, otherwise you don't get any errors.
Look at the owner of '/path/to/my/project/public/web_apps/'
I developed a simple plugin to bar files ending in .exe from being uploaded into my jira app. I overrode the AttachFile.doValidation() method to check for .exe in the filename. If it's there I return an error.
Now when I try to delete an attachment, 9 times out of 10 it won't work. I simply get the error "Failed to delete attachment with id {id}". Nothing in the stacktrace or logs indicated that something went wrong. Then it will suddenly delete succcessfully. I've found no rhyme or reason for this.
Again, I overrode AttachFile, not DeleteAttachment, so I don't know how my fix could be related to this problem. Could it be though??
If I remove my plugin entirely, I still get an error when I delete. The error says "The action can't be completed because the file is open in Java(TM) Platform SE binary". Somehow AttachFile() is leaving a reference to the file, but I have no clue where or how to clean up.
Permissions aren't the issue, because occasionally the delete command will work. It always works when the server first starts up, and after that only periodically.
We've come to the conclusion that this is a Windows-only problem, and Linux doesn't lock files. Our production server is Linux, so I'm not going to spend anymore time on this.