I have a Clear Case VOB mapped on my Z: drive in Windows 7 and checked out 2 files. All the other files are shown as read only in Visual Studio 2013 but these checked out files seem to be editable (no lock symbol like on the others), but when I try to save the file it only allows shows a "Save As" dialog and when I try to overwrite the file I get a message "Access to 'Z:...\khmwdkwdmx.d0c' is denied" (which I suppose must be some kind of generated temp file, because every time I try to save it always has a different name). If I edit the file in Notepad++ it can be saved as normal, no errors in that case.
Additional info: The problem seems to be that as I can't create new files in a clear case dynamic view only change the files I have checked out, so VS cannot create it's temp files while saving (like m4s1c0nk.swt, jl0lb2ob.255 and other random generated ones) so the file saving always fails. Is there any possible way to turn these file generations off or to generate them somewhere else?
First, make sure of the state of the files within the parent folder of Z:\...\khmwdkwdmx, to check if those two files are indeed checked out.
Second, verify is there is no other processes keeping an handle of those files, preventing Visual Studio to update the actual files.
You can also fall back to a Visual Studio session opening your view using the full path of the dynamic view (M:\MyView\MyVob\...) instead of the subst Z:\MyVob
The problem seems to be that as I can't create new files in a clear case dynamic view only change the files I have checked out,
Check if you can at least check out the parent folder, or check is associated right:
cleartool descr -l parentfolder##
(the ## are for describing the element, not the version, of the parent folder).
Try a:
cleartool protect -chmod 777 parentfolder
More generally, write issues are described in "About the error Checked out version, but could not copy data to <some-file.txt> in view", and are following "About ClearCase permissions on Windows".
Related
in InstallShield 2011, I cannot modify file permissions under Application Data -> Files and Folders. Whenever I right click on items, it shows grayed out menu buttons. I can't even delete existing entries.
In a bat script later in the installer, I can't copy over certain files because I don't have the right permissions so the installer fails when trying to reference files in BackupFiles. For some reason all the other files get copied over just fine; I can't modify those file's permissions either. I read online that you have to click the "Properties" button in that context menu to change permissions.
My version is InstallShield 2011 Premiere Edition Version 17.
I don't understand why this is grayed out. The source files do not have any restrictions on them so it must be the installer doing something related to permissions.
That boxy orange overlay on the folders and files indicates that these are coming from a Dynamic File Link. Because these files aren't actually added to your project, not all configuration options are available. You might have to edit the permissions on the source files (before build), or change your project to statically include all or some of these files. Given the size of that tree, changing it all to static could be a bit tedious. Changing parts of it (by editing the link exclusions) might be a good middle ground.
Or you could better determine what's going wrong and see if you can address it in the batch file. Assuming this is InstallScript (rather than InstallScript MSI), the entire setup along with any processes it launches should be elevated. So I'm having a hard time guessing what could go wrong. Perhaps a read-only flag? Perhaps use a tool like process monitor to get more information on that, and see if you can add a call to attrib -r, or cacls, or whatever.
I have a website with several thousand pages that I have added to TFS source control. I have created a workspace with the local path mapping to the actual file directory (so that anytime a file is saved, the actual source file is saved as well). I have added my files and then checked them in.
After checking them in for the first time I see the lock symbol next to all of the files. Now if I go to check out and edit, I can check in my changes and this shows up in the changeset, but the file remains checked out. I can view the history and see all iterations (every time it was checked in), but it still always shows the file as checked out.
I think the issue may have something to do with the fact that I created the workspace as a particular user and then made it a Public Workspace. I now am logged in as a different user attempting to check in/out.
I also just noticed that in my history it shows the changes made by UserB, but in Source Control Explorer it shows checked out by UserA
When creating this project I set my workspace to the initial source code directory. I then set another user's workspace to this same directory (it was a shared drive). Visual Studio did not stop me from doing this because this local path was set on different computers, but I believe that this was the issue.
I am building a VS 2010 installer, and I want to copy files to app folder depending on what options I select in UI (UI is not simple, so the only option is to show custom dialogs in Install custom action).
The problem is that custom action is actually executed after files are copied already.
One possible solution I can think of is to install all these files into the app dir, and then delete some unnesessary files in custom action. But these files are "secure" in some way, so I don't want to copy them to filesystem, even for a short period of time.
Any thoughts?
If your files shouldn't ever be on the filesystem, you have a problem in the requirements. The .msi storage itself is an open format and can be read by many tools, so if someone knows the file it's possible for them to find and extract it manually.
I agree that it's better to avoid deleting the files after they've been installed for two reasons. One: it avoids wasted work, and two: it won't cause repair scenarios due to missing files that Windows Installer thinks should be present. You should probably figure out how to determine whether these files should be present at an earlier stage of the installation, and set properties that cause this to happen (disable components by condition, or change feature states).
Most controls in MSI dialogs use installer properties. For example, a checkbox may use a property named MY_CHECKBOX which is set to a value or it's empty, based on whether the checkbox is checked or not.
These properties can be used to condition files:
select your setup project in Solution Explorer
click File System Editor button from Solution Explorer top pane
select the file you want to condition
in its Properties pane set Condition field to the condition you want, for example
MY_CHECKBOX = "value"
I've run into a problem with VS2010 (it also exists in the latest version, SP1 (10.0.40219.1)):
Add an existing Word file to the "Solution Items" and check this new file in.
Check the file out for editing
Double click on the file and edit it in Word (just make some minor changes)
Save the file (CTRL-S)
Now the file is removed from the "Solution Items" in Visual Studio (you may have to repeat the editing and saving a couple of times)
Update: I'm using Visual SourceSafe 2005.
Despite my research efforts I haven't really found anything on this issue apart from this Microsoft page, and I'd like to know whether there is a way to prevent this problem from happening.
Any ideas are more than welcome, thanks in advance.
G.
After further investigation I think I found the reason behind this behaviour and a workaround.
Please also note that the behaviour described in the original question only occurs for files that are added directly underneath a solution or to a folder that is directly underneath a solution.
The reason
I'm not sure whether the following is 100% correct, but the main point is how Word (and probably other MS Office apps as well) saves an existing file:
Save the current version of the file to a temporary file
Rename the original file so it can be used later in case something goes wrong
Copy the temporary file to the location of the original file, using the original file's name
Delete the original file (that was renamed in step 2)
Visual Studio picks up that the file doesn't exist (for a very short time though) and removes it from its tree and the .sln file. This can also be reproduced by manually adding any kind of file, checking it out (if not checked out), renaming it to a different name and then back to its original name => file is no longer shown in Visual Studio.
The workaround
I've created an empty project template following the steps on Microsoft's site. I also set the output to "Class Library" so that the project would compile even if no static main method exists. This template can be used to add a "Documentation" project to an existing solution. Underneath this project you can add files and edit them as you wish, as Visual Studio behaves differently and does not remove the file when it is saved in this constellation.
Obviously this approach is still not very satisfying or elegant, but I hope that it may be helpful for others who might run into the same problem.
G.
I've run into the same issue. I simply undo changes for the solution after I've closed the document file and the solution files will be as they originally were before your document changes.
At the moment when unmapping a source on TFS Source Control in Visual Studio 2010, the local downloaded files are removed automatically.
How can I keep them untouched?
Nam.
In VS2012
"You can remove the mapping in the Manage Workspaces dialog (File -> Source Control -> Advanced -> Workspaces...) Pick your workspace and select edit, remove the entry for that mapping. Then hit OK. When prompted to perform a Get you can say "no" and the items will stay on your local disk until you next perform a Get."
I added some more information on to it.
Source: Remove Mapping
Just in case anyone else need help with this because i went for hours searching for the solution....and this is the way to see all the mappings you have and remove them if wanted without deleting local files.
I have not seen this behavior. When un-mapping, are you choosing to re-download all files in the workspace? If so, choose not to do that, and the files should be preserved locally. Keep in mind that TFS is no longer tracking changes at that point, so it could get you into a lot of difficulty if you inadvertently make changes to those files.
What kind of process are you trying to implement that you need to keep these files around after an unmap? Maybe there's a different way to accomplish what you need?
--EDIT--
When you're doing this, files are just files, so you could:
do a Get of all files in that workspace
copy them to another folder on your hard drive
map that new folder
Do an "add files" on everything in the new folder structure
check in.
You will have to rebind all of the projects/solutions to source control when you do this.