We Keep Coding

S3 Multipart Upload Interruption - Can we access the parts which managed to upload to bucket

We have a "S3 Compatible Storage" type account with 2 buckets for a multiplayer game project. What I wonder is what can be done when a multi-part upload gets interrupted due to a connection issue. For ex; can I access object parts which managed to reach our S3 bucket? Is it possible to download those parts? Iirc Amazon etags object parts and gives UploadID to complete objects.(Projects uses .net sdk for s3 btw)
Thanks a lot!
[Tried to access object parts (which managed to reach our S3 bucket) of a failed multi-part upload via S3 browser.]

SharePoint file size is different than source file after uploading

We are developing a WinForms (desktop) application in .Net framework 4.5.2 with C# language.
Using Microsoft.Graph library 1.21.0 and Micorosft.Graph.Core 1.19.0 version to copy files from windows local machine to SharePoint/OneDrive cloud storage.
I tried with Microsoft.Graph library 3.18.0 and Micorosft.Graph.Core 1.22.0 and .Net 4.6.2 framework but same issue.
We are copy files less than 4 MB using following method
uploadedItem = await
MainDrive.Root.ItemWithPath(Uri.EscapeDataString(targetFilePath)).Content.Request().PutAsync(stream,
cancellationToken);
Files larger than 4 MB are being copied using ChunkUpload
var session = await MainDrive.Root.ItemWithPath(targetFilePath).CreateUploadSession().Request().PostAsync(cancellationToken);
var provider = new ChunkedUploadProvider(session, graphClient, stream, OneDriveChunkSize);
var chunkRequests = provider.GetUploadChunkRequests();
var trackedExceptions = new List<Exception>();
foreach (UploadChunkRequest request in chunkRequests)
{
await CheckforBandwidthThrotelling(fileInfo.Name, fp, cancellationToken);
UploadChunkResult result = await provider.GetChunkRequestResponseAsync(request, trackedExceptions);
if (result.UploadSucceeded)
{
uploadedItem = result.ItemResponse;
}
}
Issue: We are getting the file size larger than source after copying files to SharePoint. It works well in case of OneDrive personal using same api's and method.
I found that it's due to Metadata get added to file. We are not maintaining any multiple version of files on SharePoint.
This issue is mostly with office files (docs, xlsx and ppt) but not with txt files of any size.
The application differentiate the files mismatch on source and destination based upon timestamp and file size. As file found different size in next run, it copies the file again.
The same issue is reported on github
Some more description about issue
I am looking for a workaround to compare file size between source and destination to decide whether file need to copy again.

Botframework | Direct Line | Attachment Upload - Need more info about limitations, security and storage

I have a few questions regarding Attachment upload on direct line (webchat)
When the user uploads a file on web chat
What storage is being used ?
Can we use our own storage ?
What are the limitations ?
Size limits
Allowed File types
etc.
What about security ?
I noticed that we can upload anything from an image to an executable
Thank you,
Marc

Attachments for Direct Line are stored encrypted on Microsoft servers. The size limit currently is 20MB and the contents will be available for 24 hours. You can use links to resources (actually how you would get around size limits) instead of through the Direct Line storage, but there is no way to override the Direct Line storage if you are sending actual attachments. I don't believe there are any restrictions on file types within Direct Line.

"The request body is too large and exceeds the maximum permissible limit" when uploading block blob to Azure

I am trying to upload a 300GB file to Azure Blob Storage. Below is the code that I am using:
// content = array of bytes ~ 300 GB
using (var stream = new MemoryStream(content))
{
var blobRequestOptions = new BlobRequestOptions
{
ParallelOperationThreadCount = Microsoft.WindowsAzure.Storage.Shared.Protocol.Constants.MaxParallelOperationThreadCount
};
blob.UploadFromStream(stream, options: blobRequestOptions);
}
This operation fails with the following message error:
The request body is too large and exceeds the maximum permissible limit

I believe the issue (per comment confirming older SDK version) is the client SDK version number. Starting with v8.0, large ( 200GB -> 4.77TB) block blob sizes are supported (with blocks now up to 100MB, vs the old 4MB limit). The 50,000-block limit still applies (so, 100MB x 50,000 blocks provides the 4.77TB size).
Prior SDK versions were limited to 4MB blocks, and 200GB block blob size limit.
Larger Block Blobs are supported by the most recent releases of the .NET Client Library (version 8.0.0), the Java Client Library (version 5.0.0), the Node.js Client Library (version 2.0.0) and the AzCopy Command-Line Utility (version 5.2.0). You can also directly use the REST API as always. Larger Block Blobs are supported by REST API version 2016-05-31 and later.
More info here.

Creating Blob in Azure Blob Storage with the same name simultaneously

I have task to load some images into the blob storage simultaneously. Name of blob is defined as md5 of the blob. It can happen that different threads try to load same files from different locations.
Now I need to know how to block other threads from loading same file, if first already trying to upload such blob.

You can do it without leasing it by using optimistic concurrency. Basicly set an access condition that says this blob will be different from all etags of blobs with this name. If there is indeed a blob with some etag the second upload will fail.
var access = AccessCondition.GenerateIfNoneMatchCondition("*");
await blobRef.UploadFromStreamAsync(stream, access, null, null);