How can I delete the older versions of an excel file so that other users won't be able to restore a previous version?
I tried to copy it on desktop and then back to shared folder but it seems it doesn't work this way.
It seems that if you restore it to the newest previous version the other previous versions disappears.
Related
I have downloaded the latest version of WEKA on a newer Mac with the M1 chip and am having trouble opening .ARFF files. When I go to open the file, the file is not appearing as an option to open. It is perhaps a problem with permissions? But when I look at the permissions for the app, I am able to read and write. I am not getting an error message of any sort. I can only see the directories and no files.
Has anyone else had this problem and found a solution?
Many thanks!
I tried uninstalling and making sure I had downloaded the latest version of WEKA and I tried moving the .ARFF file to a new location.
Whenever I try to move a file into a project I have in IDEA it freezes up after displaying the the move file dialog. I've tried searching around but haven't found anything helpful.
I had the same issue while using an EAP release version. The milestone release did not behave like that.
Here is more info on the subject from JetBrains: Please note that EAP builds are not officially supported. Please use released versions from http://www.jetbrains.com/idea/download/index.html if you want stable functioning.
Could be related to https://youtrack.jetbrains.com/issue/IDEA-145305 .
ruku, I'm not sure if the EAP build was your problem, but if you're like me and are using a stable build and cannot upgrade (compatibility issues with others on my project), I recommend the workaround of just creating a new file and pasting the file content in there. It's not very elegant, and requires manual refactoring for any files already referenced within the project, but since you're moving a file into the project you shouldn't have that issue.
Like sday, it happened to me when moving a file within the project. I am not using an EAP Build. I am using 14.1.4, build #IC-141.15.32 build on June 18, 2015. I installed on 2015-09-05 from the main JetBrains page that sday mentioned. I'm using osx 10.11.1.
We want to be able to patch our product in the future by producting an ".msp". A particular exe in the .msi is missing version information.
If we create an .msp in the future, will we have problems upgrading that .exe?
I want to know whether we need to add the version information and rebuild the .msi or whether we can avoid it so we don't have to repeat our release process for the .msi.
This post: http://blogs.msdn.com/b/astebner/archive/2005/08/30/458295.aspx
explains that a versioned file will always replace an unversioned one. So, as long as the any updated version of this exe is given version information before it gets put in a .msp, then it should upgrade ok.
I tried REINSTALLMODE=amus option but it didn't work showing error message Another version of this product is already installed....
If I give INSTALLMODE=vomus option it works well. But, some files are not overwritten, not updated. Maybe it seems to be a file version related problem. Is there really no way to force WI to overwrite its files except doing major upgrade?
Take a look at the MSDN topic REINSTALLMODE property. The "v" is needed by the minor upgrade, the "o" tells it to only overwrite older files and the "a" tells it to reinstall all files regardless of hash or version.
So REINSTALLMODE=vamus should be what you need. However, if the files in the installer were properly versioned this shouldn't be a problem in the first place.
It seems that the upgrading installs don't replace files with new versions, but they actually uninstall the old setup package and install the new setup package. Lets imagine that I've installed my application and it generated some files in the install directory. Then the user gets a new version of the product and launches the install package. The package deletes the old version of the product (because the new setup package has "remove previous versions" set to true, higher version number and different product code). The files that were created by application, but not by the package, are not deleted, and this is good. But the user can install the new version to a different location, and then the application won't find the old application files. How do deal with it? Write some custom actions and conditions that skip the folder selecting screen if the application was already installed? Or maybe there is already a built-in way to upgrade the old installed files in the specified directory?
Your application should not store its settings in Program Files, they should be stored in CommonAppDataFolder, AppDataFolder, or LocalAppDataFolder. If you use one of these folders to store your application settings/data, then users are free to install it to any other location and the app will still see its settings/data.
As far as I understand, the behavior of upgrade depends on where you schedule RemoveExistingProducts action in the install sequence.
Edit: Since you can't change where your application stores its file, you will have to manually keep track of the install locations. When upgrade operation is performed, the updated product will usually be installed to the same location (this may require a change to your Wizard UI).
If you want to preserve the settings even with manual re-installs, i.e. users uninstalled your app, and then installed it again to another location, the only option I see is to store the install location in the registry. If the value does not exist in the registry, your additional actions should not be run. If the value with location of the previous install exists, you save it. Then you move the settings/data from the old location to the new (by adding temporary rows to MoveFile table). In the end you save the new install location to the registry.
Be aware that storing settings/files in Program Files may not work as expected under Windows Vista and above, especially if UAC is on; and your settings may be actually stored in Virtual Store rather than in Program Files. Updating your application would be much better option than trying to move files around.