I am try to deliver code from my dev stream to QA stream and the delivery is erroring out(unable to merge) one particular file. When I look at the file from Clearcase Explorer, it is showing the file state as 'Not Loaded, Checked out but removed" as shown in the screen shot below:
When I try to do a UndoCheckout from Find Checkouts I am getting the below error:
Error undoing the check out for 'Z:\buildSupport\...'
Not an object in a vob: 'Z:\buildSupport\...'
Pathname provided did not resolve to a version object.
Not an object in a vob: 'Z:\buildSupport\...'
From Command Line I am getting below error when tried to get status of the file
cleartool ls AuditAssignment.jsp
cleartool: Error: Pathname is not within a VOB: "AuditAssignment.jsp"
Please help to solve this issue. I am in a UCM environment.
Z:\ suggests a snapshot view which has been mapped to a letter drive through subst.
Depending on your exact OS, it could be a case of path length limit that I mention in "not able to build in clearcase snapshot csproject".
But you also have other causes, like this IBM technote suggests:
When the link is created with a relative path using the wrong case, even though the link is created, the files within that linked directory can only be viewed through the Windows command line (cmd). However, they are treated as if they are not in version control anymore.
Even if symlink is not involved here, check if there is a case issue (with the same name versioned but with a different case, like the status picture seems to indicate)
Windows would not be able to show, especially in a snapshot (UCM or not) view, two files with the same name and different cases.
It is important when the merge is done that a file 'AuditAssignment.jsp' is present on both sides with the same case.
Once the case is identical on both side, then a merge can be attempted.
There are many possible reasons.
Among them, the protection (access permission) of the parent directory might not allow you to modify it. You should check the Clearcase permission of the directory "fieldAudit". You can do so by right-clicking on the directory and look at the Clearcase property. If you are not the owner and if the group you belong to does not have the permission to modify the parent directory, you might get into this type of issue. In order to modify the access permission of the parent directory, you can will have to use the "cleartool protect" command, either as the VOB owner or either as the owner of the element.
The command would then be (for Linux/Unix):
cleartool protec -chmod 770 fieldAudit
What matter is the 7 for the group. You could give 775 or 777 (which would not be safe) depending on the policies for your VOB. Your Clearcase administrator should be able to help you on that one.
I don't have proper explanation for this issue. A senior person from another team helped and i couldn't follow what he did exactly. Basically he deleted the file from my view and recreated it. He did this a couple of times.Sorry I am not able to answer this properly.
Related
I'm trying to commit new changes to my repo, but it fails with the following errors:
error: unable to create temporary file: Invalid argument
error: unable to create temporary file: Invalid argument
error: Error building trees
When others faced similar issues, the error would point to a specific file/object which was causing the issue, however here there is no additional info to go on.
(Windows 10, tried through Terminal and cmd)
I found the issue - the project folder was being synced with OneDrive, which corrupted (The tag present in the reparse point buffer is invalid) one of the files in the objects folder inside .git. Figuring out where the issue lies could be done either visually (for me it was the only folder with blue OneDrive sync arrows instead of the green tick and the folder couldn't be opened). Another way is to clone the problematic branch into a new folder, make a small change (I created a test.txt with "test" written inside), push it to git, then go back to the problematic project folder and try to pull new changes from git. This operation failed and pointed to the corrupted object.
To solve this I looked into how to deal with files which OneDrive corrupted, and the most common suggestion was to run chkdsk c: /r /f in Command Prompt (as admin), which starts when the computer is rebooted. Beware it can take several hours to complete.
General Windows Solution (tested on Windows 10 and 11):
I'm getting the error because it appears that windows put the folder in read only mode
Deselect read only, then click apply and ok
Git really ought to print the path here, yes. The error seems to come from object-file.c:write_loose_object(), which is going to be creating a temporary file within .git/objects in the normal case.
The EINVAL error case should never occur, as the object path itself is necessarily valid (otherwise how did it come into existence?) and the generated temporary file name uses entirely "safe" characters. So the missing filename.buf in the error message should never comes out in the first place. In your case, the error does come out, and the missing %s for filename.buf means we can't see what path it is that your OS is objecting to.
You could build a debug or private version of Git (that adds the missing path) to find out, or use whatever system-call tracing facilities you have to observe the failing system call some other way. Find out why the OS is rejecting the attempt to create the loose object temporary file, and correct whatever the underlying problem may be. Meanwhile you might want to report this to the Git mailing list.
I'm using Node.js to start Watchman on Windows 2016 with a number of file type filters on a specific directory. This directory is being used for staging. Uploaded files will be routed to other folders depending on the filename.
The problem that I'm having is Watchman is picking up files that are being uploaded. It causes the moving processes to fail as it's locked. I'm thinking about using this package to check the file status (#ronomon/opened) before marking it as a candidate for moving. Is there a better way to do it?
Thanks,
Paul
Please take a look at this issue that sounds almost identical to your question; it has some other alternatives and details beyond what I've put below: https://github.com/facebook/watchman/issues/562#issuecomment-355450096
Summarizing that issue here: you need to allow for the filesystem to settle. There is a settle option you can set in your .watchmanconfig to control this:
{"settle": 60000}
You'd place that file in the upload directory (and make sure that you don't mistake it for an uploaded file and move it out) and then re-create your watch.
I have a solution containing a bunch of projects all under source control that is mapped to a local folder on a PC, but only for a specific windows user, say UserA.
Now if I log into Windows under a different user UserB I want to be able to use the same code with the same source control, without overwriting any local files (e.g. with the server version. There have been many local changes that haven't been checked in by UserA).
However when I open the solution file as UserB, I get an error saying:
The solution appears to be under source control, but its binding information cannot be found. Because it is not possible to recover this missing information automatically, the projects whose bindings are missing will be treated as not under source control
(this applies to all projects)
The next message box gives me a choice between Temporarily working out of source control or Permanently removing the bindings.
Any attempt to Map the Server folder to the local folder will result in an error stating it's already mapped. Also I said I want to use the existing local code while keeping it under source control (e.g. so UserB can check in the changes and any more changes he makes)
What is the correct way to do this?
If I have understood you correctly, you want to use two users coding in same machine with source control.
You just need to create a local mapping of the source files to a different workspace folder. More detail step for your reference:In TFS, how can I share source files in different location, in same machine, without sharing the full project
Now you have two copies of your soucre files but with different workspace in your dev machine . When "User B" want to use these files on your machine, he just need to select the new workspace to work on it.
However, if you want userB to use the local file mappinged by userA(e.g. with the server version. There have been many local changes that haven't been checked in by UserA) It's impossible and also run counter to the rules of TFS. You must check in the local changes made by userA first, then get the lastest version from server for userB.
To share a workspace on one computer between different users, you need to change the advanced permissions of the workspace from Private Workspace to Public Workspace.
This can only be done by the owner of the workspace, which is UserA in your scenario. See the question How do I choose advanced workspace options? for more information.
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
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.