Are files opened from a network drive\share copied locally?

Or, is it buffered and streamed in the same way embedded videos from the web are handled?

This is more like it. But you are going too deep with the web analogy. On any system—even a local one—content is constantly being buffered into RAM and potentially on local hard drive storage for ingestion. Meaning it’s an app by app process/decision to deal with the inherent latency in dealing with data from non-volatile RAM (storage) to volatile-RAM (what is traditionally known simply as RAM; the workspace of the machine). So a mounted volume is just like anything else; just storage. How nimble/snappy that storage is becomes dependent on network connection stability and speed.

So if you have a gigabit Ethernet connection to your server (1000BT) then speed of playback and usage of files on a network will seem close to a local hard drive. But if your network is flaky or only at 100BT, then file usage will seem sluggish.

This is why in many Enterprise environments, users copy files off of file shares to their local desktop and then copy/sync them back to the server when they are done. Data/asset usage is just tons better on locally connected storage.

Another factor to keep in mind is a network disconnect if/when a network connection goes down. The chances of your locally connected hard drive just dropping out from your system are slim to none. And if that were the case, the drive is dying. In contrast, network connections to file shares can be cut-off/dropped without notice causing you to lose data or even causing file corruption. Which is why working with network file shares is a risky thing. I’ve seen tons of people lose work due to network file share drop-outs and it is not pretty to say the least.

JakeGould

Posted 2015-01-03T02:57:10.853

Reputation: 38 217

Enterprise environments copy files off of shares for various reasons, but it has nothing to do with performance in that way, especially in a Windows environment. Oplocks handle much of the performance aspect of reading/writing files over the network by caching, allowing the user to edit the local cached version and send updates back to the server. Copying to your desktop first, editing and sending back the file is actually a far worse way to do it (as it can negate changes made by other users) and no enterprise environment where there is any sort of collaboration would ever do that. – MaQleod – 2015-01-05T18:57:41.090

To expand on reasons why they would copy off the server, edit, and write back manually, it is usually a problem with the application itself. Adobe products have major issues with network writes, and that is mainly because of how they work with files internally. These products do not update the portions of the file that are necessary - instead, they create a temp file, the temp file holds all the changes and then the original is deleted and the temp file renamed to the name of the original (you can see this all in a pcap). This process doesn't do well over networks,. – MaQleod – 2015-01-05T19:01:49.927

@MaQleod Does the Microsof Office suite of products deal with Oplocks in the way you describe? Because I have seen work/ dat – JakeGould – 2015-01-05T19:59:51.427

@MaQleod Does the Microsof Office suite of products deal with Oplocks in the way you describe? Because I have seen work/data disappear thanks to network drops in Microsoft products as well as Adobe products. I have never seen end users have a decent workflow experience when working off of network drives without copying locally. Perhaps the Enterprise environment is improperly set up, but if that is the case that then seems more like the rule rather than the exception I have seen in my professional life dealing hands on with systems. – JakeGould – 2015-01-05T20:03:00.370

Microsoft office products do act similarly. They are really not designed for that sort of collaborative work (from an application level perspective) - they are designed for personal workstation use. As far as oplocks are handled - that isn't something the application has control of - that is something the client specifies in its protocol stack. You're looking at this from too general a standpoint. So yes, they will cache the same way, they will update locally (in the way described), and then the data after the swap will be sent back to the server. – MaQleod – 2015-01-05T21:19:04.430

So then, the entire file IS copied somewhere to the local machine? And then when the file is saved the change is sent back to the server? – andrewramka – 2015-01-05T23:06:27.797

@andrewramka In my opinion, the file is not copied somewhere to the local machine and is not sent back to the server in basic server usage. What MaQleod is talking about is not really standard usage; an application must consciously make use of Oplocks for what he is describing to happen. But for basic daily end-user use, assume as my answer clearly states: Nothing is copied locally and it is only “copied” into RAM for processing. Lose your network connection when opening a file? Good chance that file will be lost or corrupted. – JakeGould – 2015-01-05T23:22:22.030

1@JakeGould, no, oplocks are not controlled within the application, it is part of the SMB stack, so if you use SMB, you use oplocks, period. If you were using Office over NFS, it wouldn't use oplocks. The oplock is transparent to the application, it is controlled by the client itself. – MaQleod – 2015-01-08T06:45:17.590

You can read up on oplocks here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365433%28v=vs.85%29.aspx. But to quote: "Typically, file systems implement support for opportunistic locks. Applications generally leave opportunistic lock management to the file system drivers."

– MaQleod – 2015-01-08T06:48:55.770

Are files opened from a network drive\share copied locally?

Answers