Dymola generates backup files with extension *.bak-mo when deleting a file. Can I turn that off completely and permanently? I use version control, so I do not need that file. When deleting packages, even whole directories are remaining. Can I turn that off also?
This can be turned off via the advanced flag
Advanced.AutoDeleteDirectories = true;
which corresponds to this setting in the options dialog:
Related
vscode keeps adding a file named .dccache. How can I prevent this?
It messes up the github diffs and I keep on having to add .dccache to the .gitignore for several different projects.
I can't find anything about why .dccache is being created in the first place
It can also be created by the Snyk extension.
I have the same file, I believe this is being created from DeepCode: https://www.deepcode.ai/
This is a code analysis tool to try to find issues. Check if you installed the DeepCode extension in VSCode if you want to get rid of this file, otherwise ignoring it should be fine.
The DeepCode plugins or the CLI is using this file to create a cache for the source code bundles send to the analysis engine. Without this cache, the collection and upload would be very time-consuming.
As it only serves as a caching mechanism, you can exclude it from git uploads and ignore it otherwise.
Snyk extention has a Help&Feedback tab, on the FAQ there is a 'Add custom .dcignore file to your workspace'.
Sometimes git ignore doesn't work for me
I used this file: https://github.com/DeepCodeAI/dcignore/blob/master/full.dcignore.js
just create .dcignore and copy all contents to that. I manually add .dccache and .dcignore just in case.
I had the same issue and when I disabled Snyk extension on VS code editor is disappeared, if you don't have Snyk installed and still have .dccache appearing every now and them, just keep an eye on the other extensions, disable each one at a time and see which one is creating the .dccache file
Is it possible to change the permissions of files that get added to the DMG volume created by install4j (via Media->macOS single bundle archive->Installer options->DMG options and files->Additional Files in DMG->"+"-> Regular file)?
I am adding a separately uninstall.app (to uninstall pre-install4j versions of the Application) but the added executable file the uninstall.app runs ends up not being executable! (I have to add all of the files under uninstall.app individually)
I have a workaround which is to include the uninstall.app as a separate File set which gets embedded within the Application.app/Contents/Resources/app folder, and then creating a symbolic link in the DMG down to that, but I'd prefer to have the whole uninstall.app separated -- it can be run directly from the DMG.
Suggestion: Allow setting permissions of the additional files (or just preserve permissions). Also a recursive "copy folder into DMG" would be good, or alternatively allow copying of an already defined File set into the DMG?
Thanks for your suggestions, I have added them to our issue tracker.
Unfortunately, it is not possible to change the permissions as of install4j 8.0.
Update 2021-02-05
This will be available in install4j 9.0.
In eclipse, you can right click in a file and then select Team / Show local history. This shows your local saves and is pretty useful.
Now, I made some changes to a file. I am 100% certain I made them. But they have disappeared. Overwritten by someone else I guess. But when I check my local history I can't see my file changes.
My question is:
Does Eclipse always update the local file history for every save? How reliable is it?
Note: I appreciate people are thinking how can someone else overwrite your files. I am working in a force.com project. When you make changes to a file they are push to a central server. There is source control per se. It is like everyone working with a shared folder.
It depends. Each Eclipse plugin dealing with workspace artifacts can optionally set a flag for local history in its API calls to the workspace resource management when deleting or changing files. If the flag is set, changed files surely get copied into local history. But every plugin can set this flag different.
So even if you might have an editor plugin which always uses local history when saving the edited file, another plugin might delete/modify the file without using local history and therefore interfere.
Summary: Local history is not a reliable way to go back to previously saved versions of a file.
If anyone else runs into this issue, check to make sure you didn't accidentally edit a file in a build or target directory. For instance if you are working on a jsp page and make edits, swear you changed it but they are no longer there in the editor or the local history when you open the file, check to make sure you weren't editing the built version by accident.
This sometimes happens if you are quick to use ctrl-shift-R shortcut to open resources. To avoid this, you can set your build or target folder to derived by right clicking on the folder and checking the derived checkbox. This will prevent the resource from showing in the Open Resource view which could save you headaches later.
To get the code back, I opened the target version and used undo to get to the edited version.
So I decided to add my referenced 3rd party dlls to source control in a separate folder called lib and then reference them from said directory.
This works just fine, but when I want to update the files, TFS seems completely oblivious to the fact that the files have actually changed. Even if I copy over the old files, there seems to be no way of checking in the newer ones. If I choose the Check-in pending changes from the source control explorer, I get an info box saying there are no changes. But if I run a compare to a single DLL between latest and workspace versions, TFS does tell me the files are indeed different.
So is the only solution to delete the files from source control and then re-add them back as the newer versions, or could I just somehow update them?
Team Foundation Server (through 2010, and with 2012's "Server Workspaces") use a "Checkout/Edit/Checkin" model for version control that differs from many other types of version control systems (eg, "Edit/Merge/Commit" systems).
In order to update your binaries, you need to explicitly check them out and update the contents. You can then check them in. This type of system is tuned for dealing with large repositories and large files like binaries since it need not scan your disk to determine whether files have changed or not.
If you prefer to work with an Edit/Merge/Commit type system, which will scan your disk looking for changes and you need not explicitly check files out, this is available in TFS 2012 (as "Local Workspaces").
Have you tried to check out for edit the file before replacing it? It works here...
We're using TFS and we're having problems when we switch branches, it's throwing up problems with the TFS bindings every single time.
We still have
.vspcc files
.vsscc files
which is I'm guessing where it stores the bindings, does anyone have any advice on how to easily switch between branches in TFS without pain?
These files are used to store files that are excluded from source control - and yes, they are themselves under source control. I've never had to worry about these before, so I don't think that's where the problem is.
Bindings are normally stored in your actual proj and sln files.
If you have problems with binding, you actually have some problem with your workspace. Either make a new workspace in a new local folder, and get everything from the server there from scratch (i.e. setting up the workspace mapping through visual studio, opening your solution via the source explorer etc. Don't use any clever tricks here - otherwise strange things happen), or try going to File -> Source Control -> Change Source Control, unbinding all projects and rebinding them. VS will blindly write the binding info anew into your project and sln files if you do this.
Especially make sure that all server paths you're checking out can be mapped to a local path.
Switching between branches is just done by opening the appropriate solution file from the appropriate folder/branch. It's not normal that this gives you problems, obviously.