Protect a file from being copied off the flash drive

Prevent people from copying files? You can't.

To put it shortly, if it can be read (or accessed in any other way), it can be copied, for a very simple reason: copying a file is loading it into memory and then writing it somewhere.

And even if this sort of protection was possible, it would be very flawed:

• At the hardware level, you could connect a logic analyzer/data logger to the USB port and grab whatever is happening here.

• If it's a document, you can write a program that just scrolls the window and takes screenshots automatically, then feed those to an OCR tool. Less than ideal, but it works to get the data out.

• Even if screenshoting is not possible, you can use a device that records directly from the VGA/DVI/HDMI output of the video card and then use image processing techniques to retrieve the relevant content from there.

• Audio/video files can be worked around by the above approach or even by pointing a camera to the screen or using an external recorder. (the so-called analog hole)

• One can use another operating system which bypasses Windows-specific protections.

It is possible to think of other (sometimes convoluted) approaches to bypass those.

Copyright infringement is a people/legal problem and can't be solved by technical solutions alone - check how often DRM/copy protection systems (which is what you want) are broken.

The concept you are asking about is called Concurrency and Synchronization control, and refers to a set of techniques to prevent simultaneous (and likely conflicting) changes to a piece of data accessible by multiple processes.

the textbook example of the concept is a married couple with a joint debit card, and 1000$ in their account. If they are at ATMs on opposite sides of town, and both withdraw 1000$ at the exact same instant, and there were no concurrency controls, the bank would dish out a total of 2000$, which obviously wouldn't be right. Its even likely that both ATMs would reduce the amount to 0, rather than subtracting 1000 each, so the bank might not even notice that they got ripped off.

More specifically, Concurrency refers to situations where multiple things happen at the same time (and the problems that can ensue), and Synchronization is a set of techniques to avoid concurrency problems, often by controlling who can change data at any given time, using locks.

To have a concurrency problem, you need a couple components:

1. the system must implement multiple processes or threads (often to support multiple users, but that is not a strict requirement.)
2. the processes/threads/users must have access to a shared bit of data which they can change.

In this case, the file is the data, and the two processes are the copy and the editor/player that are accessing the file.

Filesystems deal with file concurrency as an essential feature of any modern OS. MS filesystem APIs (.dlls) deal with this scenario by creating synchronization locks on the files when a process opens them. The locks prevent other operations on the file while one or the other process is changing the data. for normal content files, when the first process opens the file for Read/Write, it establishes a write lock which prevents all other processes from changing the file. Additionally, when that file is being written to actively, a read lock is established so that if another process attempts to read the data, it won't get part of it from before the change and part of it from after. these read locks are released almost immediately after the file is written, but the write locks persist until the file is closed. Read locks are also established when a process reads data, to prevent file changes while the read is in progress. The general idea is that you can't write while a read lock exists, and at most one write lock can exist at any given time, so a file can only be written if there are no locks or just one write lock owned by the process doing the writing.

Usually content files are accessed using what MS calls "single-write multiple-read semantics", which would usually allow the files in question to be copied, because the copy process would not require a write lock. I'm not certain exactly why your MP3 player would lock the mp3, but my hunch is that it has to do with Metadata editors built into the player. Either way, its important to note that the process itself has some control over what locks are established, and there is no good way to tell what the programmer was thinking.

Some MS Office documents complicate the issue more, because they create temporary files for editing (word and power-point primarily), which may allow multiple editors to change their own copies simultaneously, and use special techniques to try to prevent the User2 from saving the document, and overwriting changes User1 saved after User2 opened the file. Excel and Access however may block write access to the User2, and pop up a window asking if you wish to be notified when User1 has exited the file, or allow the file to open in read only mode for User2. MS Office versions handle these problems differently. For instance, with office '07, I had to close a document before attaching it to an email. in 2010/2013, I don't have to. It also makes a difference as to whether the document is accessed locally or over a network share.

This is an enormously complex set of topics, which have huge impact on multi-process/multi-user systems, in innumerable ways, so the tactics used for each situation are myriad. I have not even scratched the surface in this post. it gets really fun when dealing with multithreaded IO algorithms and database concurrency control. The links herein should give you a good starting point to explore the concepts to whatever level of depth is appropriate for your needs and curisoity.

Good luck