What I did
I just started using git, and I think I accidentally initialized a bare repository (instead of a normal one) in my www folder. So when I committed everything, I noticed it started removing everything, which I didn't expect at the time. That's where I made the mistake of killing git. Now there's two files that I can't delete/move/read/write/execute.
When I knew what git was actually doing, I then cloned the git repo in my www folder to my desktop, and it looks like I got most of it back, including those two files, which are normal, and I can write and read to them.
What I'm trying to accomplish
I realize that this may seem like an elaborate scheme to learn how to hack, but that's not the case, I own these files and my goal is to delete them, not break in. I'm unable to delete them however, as killing git seems to have messed up the permissions on the file. I really desperately need to know how to delete them, otherwise git and every backup system I use keep breaking on doing anything in this directory!
Further info:
I'm using Windows 7 Ultimate x64, and Git version 1.8.5.2.msysgit.0
Below a screenshot of the situation:
When I look at the permissions tab in the file properties, I get the message I have to have be an administrative user with permissions to view its security properties. I then clicked on continue, as I have administrative permissions (since it's my laptop). In the newly opened window I get the message I don't have permission to view its security properties. When I try setting its owner, as it suggests, I get the message "Unable to set new owner on [file]. Access denied".
I already tried using an elevated command prompt to try removing them, even forcefully.
I'm desperate, guys (and girls)!
Ok, so I wasn't able to delete the files, on Windows.. I finally did it using a linux (debian 6.whatever) live-cd, and using rm -rf logs/
So if anyone else should encounter the same thing, this is a relatively quick solution.
Related
I have used Git on Windows for a while, but recently changed the setting and got this.
On almost every command for Git Bash (also on PowerShell and Github Desktop) I get
git.exe is being downloaded on OneDrive
(translation may not be exactly the same)
The setting that changed recently is moving my repos to a OneDrive folder in order to have them synced between two sessions: that is work desktop and remote virtual machine.
I can see that this may not be ideal, but it really works for me since I have the same settings on both sessions, and not really get used to doing many commit-push-pull. Not the main topic here, but feel free to comment.
(Edit): Upon reading solution, there are other ways to set this syncing that doesn't mess up with the internals of Git. Look for that instead. Thanks.
In any case, the strange thing is that the notifications happen only on the Remote Virtual Machine, but not on the desktop.
I have seen some notifications about some files in the repos, which I then attribute to OneDrive being nosy about every move I make file I move. But then I've also seen files I don't know about, and theres always git.exe attached to the notification.
In the first scenario I have tried tuning down the notifications for OneDrive. Some might say Microsoft does have a background for not letting users setup their notifications, so I'm still looking.
Thanks.
Most file syncing tools like OneDrive and Dropbox operate by syncing data file by file. This is a great approach if you're working on a single word-processing document or spreadsheet. However, it's not as great when you're working with a Git repository.
When changing between branches or making a commit, Git changes and creates a lot of files all at once. In order to be synced correctly, all of the created files must be written in a similar order: all the blobs must be written, then the trees, then the commits, and then the refs can be updated. If you do this out of order, your repository can be corrupted, since you can have branches that refer to objects that don't exist (or objects that refer to other objects that don't exist).
In addition, these tools can end up deleting files you wanted to have in your working tree or recreating files you didn't. So overall, you don't want to sync any Git repository using one of these tools.
You can write a bundle file with git bundle and sync that, or you can use rsync to sync a repository provided it's idle (not being modified) when you do. Note that if you sync a working tree, Git will need to refresh all files when you sync it across to the new machine, and also Git doesn't try to defend against untrusted users who have access to the working tree.
It's also not a good idea to sync your Git installation itself via OneDrive, which is what it sounds like might be happening. Instead, install Git for Windows on each machine independently and don't try to sync it across. OneDrive should have configuration options that let you control what's synced.
On my home laptop with Windows 7 x64 (NTFS) some of mercurial repositories become stuck after unknown reason. The problem is when I try to run hg log or hg diff:
Can't access file
D:\user\my-hg-repo-root-path\='FRX'
In same time, icoming, pull, update, push, add, commit work well.
So, last several days i live without history or diff preview on the home laptop.
I've not found any reason for such a problem, as same as what FRX means. Do you know the reason of this problem?
PagerExtension?
That's where this ='FRX' might be coming from. Look at your ~/.hgrc.
It looks like this is a file that has been created by some windows application (from http://www.file-extension.com/files/FRX/: "As a binary form file, the FRX file extension can be found working with Visual Basic.") probably during an execution of VB programs, and it could be possible that you do not have the read rights on this file.
If this file is not important for you, I'd suggest to remove it from the working directory, maybe using admin rights.
Background: this is running on a Windows 2008 Server.
https://www.mercurial-scm.org/wiki/Workflows#Feature_separation_through_named_branches
I'm a Mercurial newbie, and am trying to follow the advice above where it says to "Merge default into your feature as often as possible" -- and I've done this a couple of times previously today, already, with other files.
However, this newest change just won't merge.
When I do the 'hg merge default' I get the error "abort: Access is denied". After googling around, I see that some people reported actually having permissions problems on the files in question. There's nothing special about the permissions on the file in question, at least not that I can see. I'm a Linux person by training, not a Windows person, so fundamentally I don't really understand Windows file permissions. Cygwin claims that the file in question is 644 (i.e., I can write to the file), which is the same set of permissions as every other file that has previously been successfully touched by the hg merge process in the past.
I took a look at the DOS 'attrib' command and it doesn't show a 'read-only' flag next the file in question, either.
If this is less a Mercurial question than it is a Windows permissions question, I'm happy to modify the tags further as well.
I'm assuming that this "abort: Access is denied" error refers to the file in the changeset that needs to be merged, and not to one of the .hg/ files, but it's a very cryptic error message -- it doesn't say which file has an access issue (and there is only one single file in the changeset that was changed -- I purposely tried to be VERY simple with this test).
UPDATE:
Did an 'hg rollback' and tried the same test of commands in the same order, leaving the files open, only with a completely different file (lib/blort.html instead of blah/foo.html).
The 'hg merge' worked just fine.
So there's probably something particularly hinky about the permissions on the specific file I started with (foo.html), or the directory that is its parent.
Another Edit
Definitely something off about the parent directory, as I had the same problem w/ another file in the directory, but the problem does not manifest elsewhere in the directory structure, only in this one directory.
Just checked the permissions on lib/ versus blah/ and they both seem the same in Cygwin, but that's only a vague approximation of the Windows ACLs. When examining those by right-clicking each directory and examining the 'Properties' Security tabs, they again seem the same for both directories, but I think the crux of the problem is that I really don't quite grok ACLs.
Is there some DOS command-line tool, like 'attrib' only more powerful, that, like 'ls' in linux, would give me more information than the confusing jumble of checkmarks I get in the 'Properties'?
Hopefully the final edit
How to diff Windows permissions
'iCacls' seems to be the correct tool for the job, and seems to have solved the problem, but I'd like to duplicate this before accepting/closing.
SUMMARY
When in doubt, use --debug on your Mercurial commands. This is a little bit 'duh' now, but thanks to #lazy-badger for pointing it out.
You can fix your Server 2008 permissions using a command like icacls path /grant domain\user:(OI)(CI)F (see e.g. http://www.petri.co.il/forums/showthread.php?t=23207), but be sure to do this from an escalated CMD window ('Run As Adminstrator'). Again 'duh' to Windows people, not so obvious to a Linux person (instead I went googling around for some DOS equivalent to sudo).
You may get an access denied error on Windows if some other program has the file open. You can try closing programs that might have any files in that tree open, or rebooting the computer (which would, of course, close all programs).
Just to note "Access denied" on merge can have two different roots: mentioned by #emil and wrong or nonexistent rights for user, under which credentials hg was started, to create temporary files in $TEMP folder
I suddenly can't save any files in any of my Xcode projects in my home directory. Not sure what caused this. Here's the error I'm receiving:
I don't think Xcode is correct, since I am the owner of -- and have read+write permissions on -- the affected files.
A few other fun facts:
I can edit these files in other applications as the same user, so the problem seems to be specific to Xcode.
Other users can create and edit projects in their home directory without issue.
Running Xcode as root (via sudo /Developer/Applications/Xcode.app/Contents/MacOS/Xcode) does allow me to edit these files.
chown, chmod -R 755, etc. on the directory containing my projects doesn't help.
Disk Utility > Repair Permissions doesn't help.
Reinstalling Xcode, clearing Xcode .plists, etc. doesn't help. Failing both on Xcode 4.1 and 4.2.
Thoughts? Hopefully I'm just missing something simple.
I've just run into this issue myself. No amount of rebooting fixed it for me. In fact, it only began after a reboot. After much frustration, I used fs_usage to observer the file system calls that Xcode and any other processes were making when I attempted to save.
The results were interesting. In particular, one of the last things I saw before Xcode loaded NSAlertPanel.nib (which I assume is the UI for the error sheet), thing showed up:
revisiond.3029 getattrlist /private/var/folders/9f/_7xjwv310nb6c7yr6py_9jtc0000gn/T/TemporaryItems
Xcode.2437 mkdir /private/var/folders/9f/_7xjwv310nb6c7yr6py_9jtc0000gn/T/TemporaryItems/(A Document Being Saved By Xcode)
This looked highly suspect to me, so I investigated this directory. It turns out that
"/private/var/folders/9f/_7xjwv310nb6c7yr6py_9jtc0000gn/T/TemporaryItems" was owned by root:staff, and NOT writable by the group. Making this directory writable by the group fixed the issue for me immediately.
So, it appears this was a bad iteration between Xcode and revisiond, which is responsible for the File Coordination features in Lion. I do not know why this problem persisted for me when a reboot fixed it for others.
Check how you have this setup in source control. I've noticed with the new Xcode that if you have this under source control (svn) that that might be blocking your ability to write over the file regardless of permissions.
You may want to do an svn cleanup
from terminal issue a
ls -laE#"
There may be extended attributes or ACL (Access Control List) permissions problems. I have had that happen. It can be really bad if it has inherited attributes
If that is the case fix with
chmod -R -N
Be careful!
Looks like I had netbiosd blocked in my firewall configuration. After unblocking it and restarting my computer, the issue seems to be resolved.
I spent about two hours with this same problem. I tried all of the above. Finally, I rebooted my machine. Everything works fine after the reboot.
Everything was working fine and i ran into this issue. I tried most of the above suggestion. Finally,the MacOSX software update resolved the issue.
How do you store file permissions in a repository? A few files need to be read-only to stop a third party program from trashing it but after checking out of the repository they are set to read-write.
I looked on google and found a blog post from 2005 that states that Subversion doesn't store file-permissions. There are patches and hook-scripts listed (only one url still exists). Three years later does Subversion still not store file permissions and are hooks the only way to go about this? (I've never done hooks and rather use something that is native to Subversion.)
SVN does have the capability of storing metadata (properties) along with a file. The properties are basically just key/value pairs, however there are some special keys like the 'svn:executable', if this property exists for a file, Subversion will set the filesystem's executable bit for that file when checking the file out. While I know this is not exactly what you are looking for it might just be enough (was for me).
There are other properties for line ending (svn:eol-style) and mime type(svn:mime-type).
There's no native way to store file permissions in SVN.
Both asvn and the patch from that blog post seem to be up (and hosted on the official SVN repository), and that's a good thing, but I don't think they will have such metadata handling in the core version any time soon.
SVN has had the ability to handle symbolic links and executables specially for a long while, but neither work properly on Win32. I wouldn't hold my breath for another such non-portable feature (though it wouldn't be too hard to implement on top of the already existing metadata system.)
I would consider writing a shell script to manually adjust file permissions, then putting it in the repository.
One possible solution would be to write a script that you check in with the rest of your code and which is run as the first step of your build process.
This script runs through your copy of the codebase and sets read permissions on certain files.
Ideally the script would read the list of files from a simple input file.
This would make it easy to maintain and easy for other developers to understand which files get marked as read-only.
Since this wasn't fully said in previous responses yet. I hate to resurrect zombied threads though.
Since adding permission support for SVN would have to accommodate multiple OS's and permission types, NFS, POSIX, ARWED, and RACF
This would make SVN bloated, possibly clash with conflicting permission types like NFS and POSIX, or open up possible exploits/security vulnerabilities.
There are a couple of workarounds.
pre-commit, post-commit, start-commit are the more commonly used, and are a part of the Subversion system.
But will allow you to control the permissions with what ever programming language you like.
The system I implemented is what I call a packager, that validates the committed files of the working copy, then parses a metadata file, which lists out the default permissions desired for files/folders, and any changes to them you also desire.
Owner, Group, Folders, Files
default: <user> www-user 750 640
/path/to/file: <user> non-www 770 770
/path/to/file2: <user> <user> 700 700
You can also expand upon this and allow things such as automated moving, renaming them, tagging revision by types, like alpha, beta, release candidate, release
As far as supporting clients to checkout your repository files with permissions attached to them. You are better off looking into creating an installer of your package and offering that as a resource.
Imagine people setting their repositories with an executable in it set with permissions of root:www-user 4777
This is the updated link for SVN patch which handles unix style file permissions correctly. I have tested out on fedora12 and seems to work as expected:
I just saved it /usr/bin/asvn and use asvn instead of svn command if i need permissions handled correctly.
Many answers have stated that svn does not store file permissions. This may be true, but I was able to solve a dll file without execute permissions problem simply by these steps:
chmod 755 badpermission.dll
mv badpermission.dll ../
svn update
svn rm badpermission.dll
svn commit badpermission.dll -m "Remove dll to fix permissions"
mv ../badpermission.dll .
svn add badpermission.dll
svn commit badpermission.dll -m "Add the dll back to fix permissions"
rm badpermission.dll
svn update
badpermission.dll comes back with execute permissions
#morechilli:
The asvn wrapper from my earlier post and the blog in the OP's post seems to do what you're suggesting. Though it stores the permissions in the corresponding files' repository properties as opposed to a single external file.
I would recommend to generate permissions map using mtree utility (FreeBSD has it by default), store the map in the repository, and, as was mentioned above, run a script that would restore proper file permissions from the map as the first step of the build process.
Locking would not solve this problem. Locking stops others from editing the file. This is a third party application which gets run as part of the build process that tries to write to a file - changing it - which breaks the build process. Therefore we need to stop the program from changing the file which is simply marking the file read-only. We would like that information to be held in the repository and carried across checkins, branches, etc.
Graham, svn doesn't store permissions. Your only option is to wrap your call to svn in a script. The script should call svn with its arguments, then set the permissions afterward. Depending on your environment, you might need to call your script svn and tweak your PATH to ensure it gets called.
I quite like morechilli's idea to have the list of files and permissions checked into the repository itself.
We created a batch file to do this for us. Would prefer actual support in subversion though...
Consider using svn lock to disallow others from writing to the file.