We are using RBS to store the SharePoint files outside the share point content database. This works nice with SP2010. but when we moved to SharePoint 2013 we found that the file has some extra data and added to the file in the RBS directory. Is there a way to ask the SharePoint not to add this extra binary data. As our users basically access the RBS through a read-only shared folder on the network and we have done a business that depends on that.
You're probably referring to shredded storage - in SP2010, there is a single FILESTREAM blob (.rbsblob) for each file version stored on an SP site (e.g. file is stored in the content database, but its content offloaded to RBS). In SP2013, shredded storage can shred a single file version into multiple smaller pieces and pads them with extra bytes, which means that you can't easily access a single file from the RBS itself - and you're not supposed to either! What that means is that when you upload a file "document.docx", you don't get a single blob, but multiple smaller blobs (depending on the size and settings) that can't easily be merged together - what you see in RBS are these multiple blobs. The best you can do is to prevent files from getting shreded, but it's a dirty way: How to disable Shredded Storage in SharePoint 2013? - however, this will only work for newly uploaded files and has impact on storage and performance (shredded storage enables you to e.g. store only deltas of a single document, say if you have 10 document versions that are 50% the same - these 50% will be shared across all versions as shared shreds instead of being stored multiple times as they would in SP2010).
One option that might be useful is to map a SharePoint site to a network drive and let users work with that instead of RBS directory directly - this way, files will get accessed via RBS without explicitly exposing the blobs (shreds) themselves.
Another option is to download/open a specific RBS-stored file by using SPFile.OpenBinary(), which will merge the RBS-stored shreds and return a single (original) file that you can then store elsewhere (e.g. into another shared folder) - this way, you're duplicating files, but that's pretty much how it's supposed to be anyway. For example, this way you can open a file "document.docx" that is visible on an SP site, but stored in RBS as 5 .rbsblob shreds, and save it as "document.docx" elsewhere (outside of SP).
RBS storage is internal to SharePoint and you should NOT access its files directly. There are no guarantees that the data will remain in the original format as stated here:
Although RBS can be used to store BLOB data externally, accessing or
changing those BLOBs is not supported using any tool or product other
than SharePoint 2013. All access must occur by using SharePoint 2013
only.
Also I'm not aware of any RBS-related configuration for the described behaviour.
Related
Is there any way upload file to Sharepoint document library together with all properties (in one REST call) ? I found recently if I uploaded a file and the it's properties (doesn't matter what properties), for Sharepoint it's a new version of the file and it's consumes storage as previous version, so for example I upload large file (4gb) and then it's some custom properties , now this files will consume 8gb storage, regardless if file itself was changed or not.
In Sharepoint SOAP it possible, but in REST seems that not.
Thanks
You have to do them separately and it doesn't actually create a copy of the file. SharePoint stores the deltas and in your case, there wouldn't be a change in the document. When you look at the version history, it can be misleading b/c you will see version 1.0 is 4GB and version 2.0 is 4GB which would make you think that you are consuming 8GB but that is not the case. If you were add a 3rd version that was 5GB, you wouldn't have 13GB used. Instead, the database will only store 5GB of data and SharePoint essentially pieces together the file from the database.
I have some files on S3 and would like to view those files in web. Problem is that the files are not public and I dont want them to be public. Google doc viewer works but condition is, files should be public.
Can I use office web apps to show in browser. Since the files are private, I do not want to store any data on Microsoft servers. It looks like even google doc viewer stores the info while parsing.
What is the cleanest way?
Thanks.
I have looked around for something similiar before and there are some apps you can install locally (CyberDuck, S3 Browser, etc). In the browser has been limited until recently (full disclosure I worked on this project).
S3 LENS - https://www.s3lens.com/
I probably get a minus here, but also Microsoft has an online viewer, which works the same way: the file needs to be publicly accessible.
Here is the link: https://view.officeapps.live.com/op/view.aspx
What I cloud add is that those files need to be publicly accessible only for a short period, i.e. until the page gets opened. So you cloud trick them by uploading the file to be viewed to a public temporary storage in a randomly generated folder and give that url to the online viewer.
Of course this is not that safe, since the file will get as some point to the temp storage and then to Google or Microsoft, but the random path names offer some degree of safety.
I've created recently a small glitch app, which demonstrates what I just explained: https://honeysuckle-eye.glitch.me/
It uploads local files to a temp storage and then opens the viewer from that temp storage; the temp storage only last for one download, so it is pretty safe.
I am new to SharePoint Online, but haven't found anything via Google: I have tons of files (read: terabytes) stored on my filesystem and on a cloud storage and want to access their metadata to allow searching for them. Is this possible without uploading them into SharePoint Online? It should also be possible to "sync" the hierarchy of the crawled folder so I can click through the folder structure in SharePoint. I do not want to store the content of these files though (for storage space reasons).
It is like having a synced folder in SharePoint where the files are searchable, but they are just shortcuts of some kind, without content.
I thought of creating some sort of timed job which crawls the file system and creates empty files in SharePoint which contain the metadata and a link to the file, but this seems very crude to me. Is there a better solution or maybe even something SharePoint Online itself provides?
// edited: I need to crawl not only files on my filesystem but also cloud storage files of different cloud storage services.
// whoops got that wrong, it is SharePoint Online, not 2013.
You can add the file share as one of the sources. SharePoint will be able to crawl & Index the files in the file share.
Steps on how to do it can be found here...
How to: Configure Enterprise Search to index a file share
Our company has a very large document library that is taking up an enormous amount of our allocated space. I want to delete the library but not before backing it up onto my harddrive, first. Can you help? I found directions that instruct to use Outlook, but I don't want put this library in Outlook. Is there another way?
You could open up the library in Explorer View, then simply select all files and copy to a local folder.
Do you want to be able to search for those files in SharePoint after you remove them from it? If yes, then you will need to move the files to a network share and configure the crawler to scan the files there. Alternatively, you could create a records center site collection in SharePoint and move the files that you don't need any more from your working site to the record's center. That way they will stay in SharePoint, but would not occupy quota in your production sites (but would still occupy SharePoint space somewhere, so this might not be an option if you absolutely need to trim down the SharePoint space).
To quickly summarise my question:
Is it feasible to programmatically change the name of a directory (with both files and sub-folders) in SharePoint? I am expecting that users will have files checked out on at least some occasions what I am attempting the rename.
The background:
I am currently contracting for a company that produces web based software (ASP.NET) with a configurable document management system. The system can be configured to use different underlying systems, with the most common environment being SharePoint (WSS 3).
I have been assigned a task to extend what has to now been a fairly simple system (simply output files into a fixed directory structure, occasionally read). Having never worked with SharePoint before I am doing some research on best practices, and am attempting to work out what is viable. At this stage I do not have access to a testing environment myself, so am limited to reading up online.
One request is to have the directory structure reflect the name (as one example) of the current client - so all documentation for a client will be in one place, and can be accessed externally via SharePoint or other compatible applications. The specification cites that if the name of the client changes then the directory structure should immediately update. My concern is that this will either directly cause errors (eg. Permission denied) or indirectly cause errors (loss of work for users who have externally checked out files).
As a follow up question if there are concerns with the above, is there a better way to implement the above? I have looked at suggesting the users use views to access the structure in SharePoint, however there is a concern from our BA that users will not be able to directly upload new files into this structure.
Thanks
The issue with Folders in SharePoint is that they are not really folders in the way you would expect of a file system. All files in a SiteCollection are stored in one big-assed table on the Database (checkout the AllDocs table).
I cannot categorically say it is safe to rename the folder without doing a bit of testing, I know that the folders "name" is not the key to accessing the document, despite it appearing to be based on the Url you see in the browser.
The best bet is to do a quick test, but I am pretty sure that your plan will not be a problem.
The potential issue is if any Content Query Web Parts etc rely on specific folders to exist or if any other "code" or "pages" look for that folder and not the folderId.
Save the content of the list before you "attempt" it in production. You don't want to loose data.
Checked out documents will still work the way you expect them to.
You may however have to run a crawl again.