Issue with renaming large files before upload is complete

[Chad_V_Kealey]

A research group at our University is using Teams/SharePoint to store large video files (a couple hundred MB up to a couple GB). They've reported recently that some files have been corrupted (they report no file size and cannot be played). I was able to replicate the behavior by uploading a large (1.9 GB) file and renaming it. This effectively killed the upload, but the file still appeared in the library with both the original name and the new one. 

The users reported that this behavior started in the past couple weeks, but I'm seeing older files in the Recycle bin that make me question that time frame (I suspect it's been happening much longer than that).

[#2]

Could also be a case of users also exiting before uploads complete? The UX IMO isn’t that great either way. When dealing with large files or larger amount of files. I always recommend uploading via Sync (OneDrive client) and working with files that way. It’s way more forgiving and reliable or get files up to SP/ Teams.

[#3]

@Chris Webb , they are working in Teams and, according to the person reporting the issue, typically "drag the files into Teams" (no idea if they're using the web client or desktop app). The (potential) problem with the sync option is that the files in question are video recordings of clinical therapy sessions and some of the clinicians are working on personal (not University-provided/managed) devices without proper encryption or other security measures, so storing them locally on the machine violates one or more privacy regulations. The videos are recorded locally using Zoom. The clinicians have been instructed - immediately after the conclusion of a session - to upload them, ensure the upload was successful (ie: play the video), then delete the file from their device. While they insist that everyone is following that protocol, I suspect they are skipping the "ensure the upload was successful" part. 

[#4]

Can always utilize files on demand and instead of delete once “moved” and synced can turn it to Online only which will remove the local copy, but that might be too much overhead.

They have updated Teams file tab in the past few months so that could be the culprit of the issue. There was a way you can load up and link to an online only (WebDAV) link to SharePoint libraries. This might be an option as welll.

[#5]

@Chris Webb Yeah, if these folks can't wait for a file to finish uploading to rename it, then expecting them to wait and check that it's finished syncing, then right-click and "free up space" is just asking way too much. Thanks for the info and suggestions, though. To be clear, I saw the same behavior whether I was uploading directly to a SP Doc Lib or the Files tab in Teams (browser or desktop app). The only discrepancy is that in SP, the file appears in the library as soon as the upload starts, while in Teams (either front end), the file name doesn't show up until the upload finishes OR you do a manual refresh of the Files tab.

In any case, SharePoint should (IMO), either lock the file from changes until the upload is complete or (better) queue changes so that they aren't actually applied until the file is all there.

[#6]

@Chad_V_Kealey  it usually does I thought. Maybe only on file edits. Anyway, the "Open with Explorer" option could work, but the negative is it requires Internet Explorer to work. That works like a direct network drive to the Library location. 

[#7]

@Chad_V_Kealey 

You have several options going forward.

a. OneDrive for Business (ODFB)
This requires software on the client and also leaves the original file on the clients. This is likely going to cause conflict with the governance folks. You will also need to train users how to use ODFB properly and not end up with dozens of incident tickets.

b. Use "Open with Explorer"
It has deployment drawbacks like it requires IE and also ActiveX but it also has technical drawbacks (the maximum file size is controlled by a registry setting on the client and this is typically 50 - 100 MB.
I am not a fan of "Open with Explorer" even if the maximum file size is increased since I have encountered several problems (e.g. 0 kB files, files not uploaded and no errors, inefficient protocol, ...).

c. Use browser-based apps that address key issues like
- robust uploading (e.g automatic checks that ensure the file is uploaded completely, retransmission if an upload request fails, ...)
- support for very large files (some tools can now even support 100 GB files by uploading a large file in chunks)
- avoid configuration / software installs on the client
- prevent renaming until the file has been completely uploaded

For example, in Teams you can add a new tab that uses the standard web site app to open a tool (e.g. here ). Users can upload one or more files using drag and drop, select content type (if multiple exist) and set metadata. Some tools can also extract metadata from the media files (e.g. duration, location, date time taken, ...) and capture the values into SharePoint columns. During the upload they cannot rename the file.
NB: it still requires an effort from the user to delete the original file.

To summarize, you can use technology to address the key issues but it also requires a minimum level of commitment from the users.

Paul

[#8]

@Paul de Jong , thanks for the info on other options. Even if I wanted them to use "Open in Explorer" (which I don't), many users have Macs, so no IE, and the file size limitations would be too restrictive.

I think the common theme here is that there is no silver bullet for this problem and user education, training and adherence to proper procedures is going to be key.