Missing and incorrect error handling

The most important problem with your code is that you either don't handle errors, or in some other cases handle them incorrectly.

Already at the start of main() you check if at least two arguments are passed. If not, you silently return 0, which means success! You should instead first print an error message to std::cerr, so the user knows what is wrong, and then return EXIT_FAILURE, so that in case your program is called from a shell script, there script can notice the error and won't continue as if nothing was wrong.

The next problem is that when it comes to I/O, almost any operation can go wrong. So while you check if the files are opened correctly, you don't check if the read and write operations actually succeed. This can cause silent data corruption, and the read thread can actually go into an infinite loop (as a read error halfway in the file will not set the EOF flag).

Make sure you check after each read/write operation if the stream is still good().

eof must be guarded by the mutex

You are only guarding buffer using the mutex, but the state of eof is something that should also be updated atomically together with buffer. Currently there is a bug where the write thread can be suspended right between the end of the while() loop and before it checks eof. The read thread might then read some more chunks and then reach the end of the file. It will push the chunks to the list and set eof. Now the write thread resumes, checks eof and thinks it is already done, when there are still unwritten chunks in the list.

Unbounded memory use

If writing the output file is slower than reading the input file, the linked list will become longer and longer. This can be a problem, since disks are typically much larger than the amount of RAM in a computer, and so it is quite possible for a file to be larger than you can fit in RAM. There is also no performance benefit from having lots of chunks in memory.

I recommend you limit the amount of chunks to just 3; one chunk is for reading, one chunk for writing, and another chunk to handle temporary read/write speed variations. You can add more, but any benefits greatly decrease after that.

Unnecessary copying in memory

In copy(), you first read data into the local variable chk. When the chunk is full, you then copy that chunk into the linked list. This can be avoided in several ways:

• Use std::unique_ptr<Chunk>s, so you can std::move them from a local variable into the list without actually copying the contents.
• Use std::vector instead of std::array, as std::vectors can be efficiently moved by themselves.
• Use a std::list<Chunk> for the local variable as well, and then splice() that into buffer.
• Just like paste() works on a Chunk that is stored inside the linked list, you can first emplace_back() an element to the list, and then read() into that.
• Prepopulate buffer with a fixed number of chunks, and treat it as a ring buffer.

Avoid manual lock/unlock operations

Calling lock() and unlock() manually is often a cause of bugs. It's easy to forget doing this in the right order, and even if it looks correct like in your code, consider what would happen if an exception was thrown by outputFile.write(). (Well, nothing bad luckily, but did you consider it to begin with?)

This also brings me to:

Use wait() with a predicate

It's almost always better to use the version of wait() that takes a predicate. This makes it explicit what you want to wait for, and the check for it will be done at exactly the right moment.

Pass std::istream instead of std::ifstream where possible

copy() and paste() don't care whether they are copying from a file on disk, or from any other type of stream. So you can make them more flexible by making them take references to std::istream and std::ostream instead of references to std::ifstream and std::ofstream.

What if you want to copy multiple files?

Your program can only copy one file at a time. Not just because you only take two command line arguments, but also because you are using global variables, so you cannot safely call p4_copyFiles_thread() from multiple threads. Ideally you'd store all the state related to a copying operation in a struct or class, and pass a reference to that to the threads.

Minor issues

• There is an unnecessary call to srand(). Avoid C random number functions anyway, and prefer the ones from C++.
• Unused variable chunkIndex.
• Use '\n' instead of std::endl.
• Don't use int to store sizes. Consider that gcount() returns a std::streamsize, which likely is larger than an int. Even if you never expect this to be larger than 1048576, it's best to use the right type. This might also avoid some compiler warnings.
• copy() and paste() are very generic names. It would help to make them more unique, or put them into a namespace to avoid naming conflicts in larger programs.
• The name p4_copyFiles_thread() is quite bad. What does the p4 stand for? Why does it use the plural Files when it can only copy one file? I also wouldn't add thread() to the name; it doesn't return a thread or use just one thread, and as far as the caller is concerned the function blocks, so it that threads are used internally is not relevant to the caller.
• C++17 introduced std::filesystem::copy_file(). It doesn't say whether it uses threads, but that doesn't mean it is not efficient. It would be interesting to compare it against your code.

Do not return a successful exit code on failure:

if (argc < 3)
    return 0;

If an incorrect number of arguments were provided, you should return EXIT_FAILURE from <cstdlib> and print an error message to standard error, not silently return success.

Furthermore, prefer EXIT_SUCCESS and EXIT_FAILURE from <cstdlib> instead of using magic values like 0, 1, et cetera.

You are doing the same thing in p4_copyFiles_thread(), where when the files can not be opened, you silently return and still print the time it took for the whole copy. Consider changing the return type of p4_copyFiles_thread() to bool, and return false if the files can't be opened. This way, callers can detect (main() here) whether the operation was successful or not.

You also need not return 0; at the end of main(), as that is the default behavior.

Errors are printed to standard error:

std::cout << std::strerror(errno) << " Error opening file " << destination << "\n";

In the case that standard output is redirected to a file or a pipe, the error message would not appear. This should use std::cerr instead.

Do not unnecessarily flush standard output:

std::endl flushes the internal buffer along with printing a newline. That doesn't seem to be the intended behavior here (and also is not required), and can be replaced with a simple '\n. Standard output is automatically flushed on program exit.