We've got an issue with SharePoint where we keep running out of space on our Team Drive. We know why, it’s because with versioning turned on all changes are stored and with some of our larger files (e.g. MS Access databases) that can quickly add up.
What I need is a way to either add some columns to show a count of the number of versions a file has and the size of the sum of those versions, so I can then sort and find the offending files quickly. Or are there any other solutions to quickly track down which files are adding bloat due to versioning? Powershell? I should add that I don't have network admin, only local admin on the machine.
This is the interface I'm working with, there are obviously files within each folder that these columns would reference:
This would require to write custom code to update as report.Please refer for more details to update according to your requirement.
https://www.sharepointdiary.com/2013/01/document-versions-size-report-powershell.html
Related
Most of my projects have files scattered in different directories. I am just checking out vs code and am wondering if there are sufficient project management features to suit this need.
Ideally, it would have a way to place files from different locations into a named 'group'. The group could be opened and closed (I mean brought in to view, or loaded into vs code) easily via a pick list. A file could be moved from group A to group B; the file location on disk would remain the same, just it's membership in a group would change. I would want the relationsip between the groups and the related files to be savable so that the same groups and associated files would be accessible after vs code as been closed and the opened again.
vs code looks very capable, but I've only gone over a few tutorials and haven't use it for anything real yet. It does say it's file and folder centric, and OS level folders are not how these files are organized. Maybe there is a feature I've not seen yet or a plugin.
I too was looking for something similar, but unable to find a solution. I did find a work-around though. There is an extension called File Group that allows creating a group of file with full path to locations of each file. New to vsCode myself, it took me a while to figure it out, but worth the effort. Hint, once installed, go to settings, Extensions, File Group and Edit in settings.json to add your file list.
I am developing on two machines (switching PC and laptop during the week) and try to find the best way to synchronize a limited amount of dummy data in the mongodbs running on each machine.
My first quick & dirty idea was to track the relevant files, containing the collection data inside of a db folder (inside my project folder) by Git.
I saw for example files named e.g. collection-0-1858325258041703863.wt which seem to contain what i am after.
However i am not sure about the rest e.g. index-1-1858325258041703863.wt files, sizestorer.wt, WiredTiger.wt etc..
Which are the files i have to track and which are the ones i can ignore?
I am aware that i could create a mock server with only json files and that saving binaries in VC is bad, but still i am curious if this way is possible (Mainly because working with MongoCompass is way easier than editing json files)
My media file contains three folders, of which, I want to have only one of those to be installed on user’s machine based on his selection.
One quick and dirty fix for this is to install all the three folders onto the user machine and then delete two of the unwanted ones. This is additional work and users might not like this. Is there a better way?
That's what installation components are for. You can select them programmatically like this:
context.getInstallationComponentById("123").setSelected(true)
You can configure installation components on the Files->Installation components step.
Sometimes when we issue an upgrade to our application we need to install some files to the application's Data folder. We want to make it possible for the users to move this folder to a place of their liking. But how to deal with this at install time?
I was thinking of deploying to the user's AppData folder and have the application somehow check there for new files at startup.
Any advice or references would be very welcome!
We use InnoSetup for a VB6 application if that matters for your answer.
Generally the best solution I've found is to allow the user to move the folder from within the application.
This allows the application to keep track of where its data is being kept (by adding a reference to it in a file or registry entry which it accesses at load time) and to access it seamlessly in the future.
Your update routines can then also access this information to determine where to place the update files.
Alternatively, make sure the folder name is as distinctive as possible and add a search routine to look for the directory in a number of sensible places at load time. Then write your manual specifying that the data folder can be moved to one of those locations ONLY.
Wouldn't the users just run an update or patch package? I'm not sure why they'd want or need to see such files. It's pretty rare for commercial software to offer users the options of where to store program settings and other internal-use files.
Give some thought to this before putting a lot of stuff into users' roaming profiles. You might want LocalAppData instead.
We (occasionally!) have to issue hot fixes for our product and do this by reissuing the affected files directly rather than with a new installer. The product has a large number of pieces, some managed code, some unmanaged.
Currently development flags which build artifacts (exes, dlls) need to be shipped in a hot fix. We'd like to be able to identify these automatically by comparing them to the previous build. A simple binary diff doesn't work since the version numbers on all the files have changed as stamping the files with a new number if part of the build.
Are there any tools that will do a more intelligent comparison and decide which files should be included? We'd still have a developer check the list, this is more to catch files the developer didn't think of than the other way around.
(Note: changing the hot fix/build process is not an immediate option, whether or not we should be shipping individual files is a different discussion!)
These are the options I see:
On your build machine get a report of the files that were changed and use the directory structure of the file path to determine which dlls were really updated. Not sure if this breaks your "no build process changes" rule or not.
If you want to wait until after the build I would recommend using a binary file diff tool like http://www.romeotango.com/Downloads/FileCompReadMe.txt. Using that you can get back a set of diffs so you just need to get your script that uses the tool to ignore the diff that occurs as a result of the version number. You can figure out the pattern to how the version number appears by using a controlled scenario where you know the two binary files are the same except for the version number and note where the differences are. Do that for a few of your dlls and hopefully a pattern emerges enough so that you can script it.