VSS Analyze - Access to file [filename] is denied - visual-sourcesafe

Our VSS database appears to be horribly out of shape. I've been trying to archive and run "analyze" and keep getting "Access to file [filename] is denied. The file may be read-only, may be in use, or you may not have permission to write to the file. Correct this problem and run analyze again." No one is logged into SourceSafe (including myself) and I'm running the analyze utility from the VS command prompt as follows:
analyze -v -f -bbackuppath databasepath
I get similar errors if I try and create project archives from the ssadmin tool.
The database is on a network share, and we're running VSS 2005 v8.0.50727.42. I'd love to be able to do this, as it would be a first step in a move away from VSS.
Thanks in advance.
More Info
Every time I run analyze, the file that spawns the access denied message changes. It's almost as if running analyze unlocks that file so that the next time I get through to the next one.

I had this issue with our VSS database as well when we tried to most recently analyze and repair.
We did a few things to get it working.
Turned off the network share, apparently we still had users accessing the share that we couldn't see, this helped most of the time.
Otherwise we copied the repository locally, then ran analyze on it from there.
Neither solution is ideal, but we were in a critical situation and it was the only way we got it to work.

Related

Windows 10 Tortoise SVN Permission Denied: txn-current-lock

Can't open file '/svn/p/thegreatwar/svn/db/txn-current-lock': Permission denied
Hello. Me and my mod team have been using an SVN repository created by a now long-since gone mod member. It has been working flawlessly until today, when, just after attempting to commit changes to a file, the system threw the above error. I've been accessing the repository through svn+ssh.
As with everything that keeps working in spite of a general ignorance on HOW it works, I find myself at a complete loss. Indeed I have no coding knowledge and although I've made a few attempts to copy-paste suggested code snippets from this site into the file settings/subversion/properties thing I'm still no closer to solving the issue.
For what it's worth the only user on this computer has full read/write/etc permissions on the folders involved.
I can't seem to access the file that is causing the issue, either. Someone suggested deleting it in another thread but I can't find the /p folder.
I have the same problem modulo project name difference. It seems that mine is caused by the ongoing sourceforge.net transfer to the new datacenter, see https://twitter.com/sfnet_ops
If your svn server is also on SF, this might explain your issue.

undefeatable TFS error: TF400030: The local data store is currently in use by another operation

No matter what I do, when I touch TFS in any way, it gives me the error:
TF400030: The local data store is currently in use by another operation. Please wait and then try your operation again. If this error persists, restart the application.
Well not everything, I can see a list of workspaces (all 1 of them). But trying to view the workspace in the source control explorer will only show "Working..." Pending changes can only show me there are 654 included changes (a migration, don't judge), but none of the actual changed files and strangely none of the excluded changes.
I tried to nuke this workspace and rebuild it from scratch. But even using tf.exe workspace /delete ..., right after a fresh reboot, will give me the above error.
I tried deleting all VS / TFS related folders from AppData\Local\Microsoft and running devenv.exe /resetuserdata afterwards as explained by Willy-P. Schaub.
Then running tf.exe workspaces results in No workspace matching * found on this computer. ... until starting VS again, after which my workspace is visible again
As explained by Philip Kelly the TF400030 error might be because of a scanner running. But I don't know how to locate / kill such a scanner and no process on my PC is doing any significant IO.
I fear spending the time to reinstall VS would result in this exact same situation and reinstalling my PC seems a bit excessive.
Is there a way to make the TFS client forget about my local workspace? Or even better hunt down and kill whatever other process causes the TF400030?
sigh sometimes the answer is so easy: I just rename the mapped folder on disk and TFS started responding again.

Mercurial (hg) can't access file ='FRX'

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.

Unable to access Temp files while debugging winForms project in Visual Studios 2010

I have several programs that I have created in vb.net visual studios 2010. I have been working on these programs for months with no problems. Recently I started having an issue where I can no longer access my temp directory while debugging within VS. I can't use My.Settings anymore because these use those temp files. This is the error I get:
Failed to save settings: An error occurred loading a configuration file: Could not find a part of the path 'C:\Users\USERNAME\AppData\Local\PROGNAME\PROGNAME.exe_Url_gty0snnfox5ji5xgprklljwb0e0mthek\1.0.0.0\nl3u0fw2.tmp'. (C:\Users\USERNAME\AppData\Local\PROGNAME\PROGNAME.exe_Url_gty0snnfox5ji5xgprklljwb0e0mthek\1.0.0.0\user.config)*
This file is there though.
I also get an error when trying to use my web services. I get this error:
Access to the temp directory is denied. Identity 'DOMAIN\Username' under which XmlSerializer is running does not have sufficient permission to access the temp directory. CodeDom will use the user account the process is using to do the compilation, so if the user doesn�t have access to system temp directory, you will not be able to compile. Use Path.GetTempPath() API to find out the temp directory location.*
I used the Path.GetTempPath() as the error says and I am trying to access: >"C:\Users\USERNAME\AppData\Local\Temp\"
I have tried going to these folders and making sure that I have the security set to allow everyone complete control. I believe it is a problem with VS not my program because I get the same problem on all of my programs, some of which I haven't opened in months. I did a repair on VS.
I can't think of what might have changed to cause this to stop working all of a sudden. I traveled to a customers facility where I had to change some network settings, but everything should be set back as it was now. My temporary security certificate expired, but I created a new one and now the certificate I am using to sign these applications is in my trusted root on certificate manager and looks to be valid. I should also mention that this is a clickonce deployment and the deployement works fine on my computer and others, it is only while debugging that I have these issues.
I have been running this down for weeks and spent countless hours looking for a solution and have come to a brick wall. Does anyone have any suggestions?
Thanks ahead of time for your help and time! Please let me know if I can clarify anything.
It turns out that the problem was coming from the fact that somehow one of the folders in the filepath to my user.config file got changed. Somehow a .vshost got thrown in on one of the folder names. I still have no idea how this happened and what caused this to happen, and I am not 100% sure that I have gotten to the real root of the problem, but for now, I am able to debug again. I changed the file name back to what it was supposed to be and the errors have stopped. Now lets just hope the file name doesn't get changed back again.

Logging into TFS on a Mac

I got Team Explorer Everywhere so we can use TFS on the Mac Mini we got to test Iphone apps. Since we're using XCode for phonegap, we need to use the commandline program and it is giving me a lot of grief.
What I've done so far (Listing out for anyone who stumbles on this so they can use it):
-Downloaded the trial (free)
-Set the path using PATH=$PATH\:/FOLDERLOCATION
-Accepted EULA and got trial product key... for command line program (tf eula/tf productkey -trial)
-Set up workspace:
tf workspace -new WORKSPACENAME -server:http://SERVERNAME:PORT/FILEPATH -comment:"WORKSPACENAME" && prompted for username -> domain -> password
-Trying to setup the folder path (Fixed):
tf workfold -map SERVERFOLDERPATH LOCALFOLDERPATH -collection:http://SERVERNAME:PORT/FILEPATH -workspace:WORKSPACENAME && prompted for username -> domain -> password
-Make sure I can check out/check in (On hold):...
The error I'm getting right now is "An argument error occurred: First free argument must be a server path." This is what I've been following ever since I got the path set, but I think the versions are different because mine doesn't seem to be set up the same. Any help at all would be appreciated, and I'll keep up with the post as I figure parts out because there doesn't seem to be much online that I can find on TFS on macs.
Update: As normal, I'm an idiot. Have to put the options at the end of the command and have to have the serverfolder path as the first thing after -map. Now I just need to figure out how to use the damn thing. I'll post any other questions I have and try to get all the correct commands up for the selfish reason of having them somewhere in case I forget them later.
Update 2: The mapping hasn't worked out as well as I'd hoped, it seems a combination of my unfamiliarity with Unix/Mac file systems and some settings being missing is keeping me from using 'tf get' to load all of the test data I was trying to get. I'm planning on trying again after I get the location of where my boss wants the data saved and after I can look into something that would save the workspace so it won't say that it can't find the map path every time...
It looks like you're setting up your workspace and some working folder mappings just fine, after the edit. If you're having problems doing a tf get after this, then there are some common problems that might be occurring. TFS workspaces can be a little bit opaque and having a better understanding of them can sometimes help you understand where the problem is:
Team Foundation Server requires a workspace to be configured before you can get files out of source control, edit them or check them back in. A workspace basically simply contains working folder mappings that map your local path(s) to server path(s).
Workspaces are stored on the server and are uniquely identified by your computer's hostname, your username and the workspace's name. A cache of this information for the local host is saved on the client. This implies:
If you remove a workspace on the server, your workstation will be unable to connect.
If you remove the cache, your local computer will not be able to identify the workspace based on working folder mappings until the cache is rebuilt (which happens every time you connect to the server.)
If you change your username or local workstation's name, you cannot access those workspaces.
(Note that very early versions of the Teamprise command line client had certain issues on Mac OS that made identifying the local workstation name difficult. This is fixed, however, in Team Explorer Everywhere.)
Because you can have multiple workspaces for a single server on a single workstation, you can't always simply provide server paths to tf commands, since server paths are ambiguous. ($/ exists in every workspace, for example.) So the command line client resolves paths based on the current working directory and/or the arguments provided. Meaning that you can run tf get foo.txt if you're in a working folder, or you can run tf get /tmp/foo.txt if /tmp is mapped.
One more point - the configuration data for Team Explorer Everywhere is shared between the TFS plug-in for Eclipse and the command line client. So if you're more comfortable using a GUI to set up your workspace(s), you can do that and then use the CLC as you see fit. You don't need to be a Java programmer to use Eclipse - simply download Eclipse and install the TFS plug-in for Eclipse into it, and select Window > Open Perspective > Team Foundation Server Exploring. After that, you'll have the full GUI Team Explorer experience and this perspective will be restored when you open Eclipse, so you won't even need to worry about the Java IDE bits if you don't want to.

Resources