Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

File this under Weird: In Monterey copying a file with Finder corrupts the data in the target file

I have a really odd problem where files are being corrupted when I use Finder to copy them from my MacBook Air to my Mac Mini server. I only noticed this after seeing video glitches when I went to play the files back on my TV. When I compared the local files with their copies on the server, whole sections of data had been replaced with #00 characters.

If I generate an MD5 hash then I can check the copied file against the original, which in this case shows that the source and target files are clearly different. Initially I thought it might be a problem with my wireless network, but what is really weird is that when I copy the same file from the MacBook Air to a locally attached USB SSD drive then it is corrupted in the exact same way - the MD5 for the corrupted file on the SSD is the same value as the corrupted file on my server.

The source computer is an Intel MacBook Air running the most recent Mac OS Monterey 12.3.1. The server is an older Mac Mini running Catalina 10.15.7. I don't think the old software version on the server is a factor as the same corruption happens copying the file to a local USB SSD disk. Rsync copies the file correctly to the USB SSD Drive, so I think it's the Finder drag and drop that's causing the problem. I don't recall seeing this problem before upgrading the MacBook Air to Monterey.

Has anyone seen anything like this before?

Thanks for your help,

Steve

MacBook Air (2020 or later)

Posted on Apr 30, 2022 11:38 PM

Best reply

Steve_Agnew_NZ Author

Level 1

17 points

Posted on Aug 25, 2022 3:56 PM

OK, here is what I am seeing. I used QBitTorrent to download the file Only.Murders.in.the.Building.S02E10.1080p.WEB.H264-CAKES[TGx]. The MD5 hash for the only.murders.in.the.building.s02e10.1080p.web.h264-cakes.mkv file is f63c9b25296bdbf4ae92640c5a65456a. If I use Finder to copy it onto my USB SSD drive, the MD5 for that file is d54e47ed0557d5239a3d656dd3831241, so clearly the files are different.

If I use cp or rsync to copy the local file onto my SSD drive it copies correctly with no corruption - they have same MD5 hash as the local file.

I opened a terminal window and use the cp command to create a duplicate copy of the original .mkv file which I called test.mkv, which has - as you would expect - the same MD5 hash as the original. If I copy this file to the SSD drive it copies correctly with no corruption. Let's try something else. I opened the original .mkv file in HexFiend and used the Save As option to duplicate it without editing it. Copying that duplicate file to the SSD works correctly too.

Copying the original .mkv file over to the SSD drive once more using Finder, I get exactly the same hash as the earlier corrupted copy, so it is being repeatably corrupted in exactly the same way. I renamed the original file and then used Finder to copy it and it was corrupted in exactly the same way.

So Finder is corrupting the file during the copy, but what does it actually look like? I wrote a program to compare the two files which produced this:

Size for both files is 1421335900 bytes

Matched 135139328 bytes from 1 to 135139329

Cleared 45056 bytes from 135139329 to 135184385

Matched 851968 bytes from 135184385 to 136036353

Cleared 40960 bytes from 136036353 to 136077313

Matched 82153472 bytes from 136077313 to 218230785

Cleared 4096 bytes from 218230785 to 218234881

Matched 28672 bytes from 218234881 to 218263553

Cleared 16384 bytes from 218263553 to 218279937

Matched 43192320 bytes from 218279937 to 261472257

Cleared 94208 bytes from 261472257 to 261566465

Matched 58478592 bytes from 261566465 to 320045057

Cleared 16384 bytes from 320045057 to 320061441

Matched 42364928 bytes from 320061441 to 362426369

Cleared 40960 bytes from 362426369 to 362467329

Matched 25534464 bytes from 362467329 to 388001793

Cleared 249856 bytes from 388001793 to 388251649

Matched 10924032 bytes from 388251649 to 399175681

Cleared 57344 bytes from 399175681 to 399233025

Matched 624123904 bytes from 399233025 to 1023356929

Cleared 20480 bytes from 1023356929 to 1023377409

Matched 397958492 bytes from 1023377409 to 1421335900 <EOF>

Processed 1421335900 bytes.

The pattern of the corruption is that every so often during the copy, large parts of the data are zeroed out in the target file. The file sizes are identical. But it doesn't happen on every file - just on the original file downloaded by qBitTorrent. You programmers might have noticed some hinky numbers there.

So the symptoms are:

Using Finder to copy the file results in a corrupted target file (MD5 mismatch).
Source and target file sizes are identical.
Large sections of the target file have been zeroed out during the Finder copy.
It is repeatable. If you copy the file using Finder once more it is corrupted identically (Same MD5 as the original copied corrupted file).
If you duplicate the file (using cp), Finder will copy the duplicated file correctly.
If you copy the file in a terminal window using cp or rsync it copies correctly.

If you are seeing this problem please report it to Apple so we can raise awareness of it and get it fixed.

View in context

Similar questions

57 replies

Jun 6, 2022 5:19 PM in response to Steve_Agnew_NZ

I have filed a report with Apple with some more examples showing flac files being corrupted during a drag and drop copy onto a local USB drive and being corrupted (identically!) when dragged and dropped into my Public folder on my server. Now running Monterey 12.4 and it's still corrupting data intermittently.

Jun 6, 2022 6:22 PM in response to Steve_Agnew_NZ

This is very similar to how my problem started, was copying files across wifi network from my macbook onto mac mini with attached USB hard drive. Only noticed when videos started randomly skipping or shuttering. Took until recently finding this thread to realize what the problem was. Got a new hard drive and restored the mac mini and nothing had worked. I realized the problem only occured when the file was copied in some way. Funny thing now is it does the same thing on both macs, my macbook running Monterey 12.4 and my mini running some version of Catalina. I upgraded my macbook to monterey within the last few months and that may have been when it started, but I am not sure.

Jun 7, 2022 3:58 AM in response to Steve_Agnew_NZ

Additional point to note:

1) Using MD5, my files are corrupted when copied via WiFi from a MacBook (APFS on Monterey 12.4) to a Raspberry Pi 4 (OpenMediaVault with an external EXT4 hard drive)

2) No corruption when copied over hard wire ethernet. Yay.

3) I will report back if I get chance to test with a USB stick or WiFi to another machine.

Jul 8, 2022 9:02 PM in response to StephenMcHugh

I have this same problem trying to copy video files to a USB drive on my 2015 Macbook Air. Large files seem to always fail. The OS is 12.4 now. It is driving me nuts, and I even got a new SSD because I thought that was the problem. Have tried different USB drives, same result. What am I supposed to do, use cp from a terminal? I know how to do that, but it seems like a lame and troublesome solution because I copy lots of video files all the time, and I'm supposed to do this by hand? I type very fast, but this is not the solution. Never heard of rsync before but apparently it is part of the OS now. Also requires typing. I will try just copying over the network next, but if the problem is with Finder, then it should reproduce the same problem as the OP had. I'll have to create a NAS drive and connect to the network with a dongle and cable, but this is also not the proper solution to whatever is plaguing finder, if indeed finder is the problem. And actually it won't work for me, because I want the files on a USB because I want to play them on a TV that is NOT connected to the network, nor do I want my TV ever connected to the network. I am very tempted to just change my OS to Linux.

Jul 8, 2022 9:37 PM in response to macsnotgnu

Does it work properly if you use cp to copy the files? It would good to have another person that can point to a possible problem in finder. I’m onlyusing rsync because I haven’t used cp before.

I have sent some examples and analytics to Apple Support - haven’t heard back for a couple of weeks but the person I was talking to could see how serious a problem it might be. My case ID is 101725043882 if you want to contact them yourself.

Jul 8, 2022 10:17 PM in response to Steve_Agnew_NZ

OK so apparently I did not do my due diligence. I am able to copy just fine using Finder drag and drop! (well I only have tried with a 2TB video that I was having trouble copying before) to both an external 3.5" hard drive, over USB, and an external drive made from my old SSD, which should have the same exact filesystem as my computer. I checked the MD5 sum. The problem seems to arise when I'm attempting to copy to a couple different Samsung U3 MicroSD using either an SD adapter (and the built-in slot on the Air) or a couple different dongles. I am now wondering if it has to do with the fact that my MicroSD cards are all UHS-III (U3). Apparently the 2015 Macbook Air does not support UHS-III, only UHS-I and UHS-II, and now I'm thinking that maybe my USB dongles/adapters also don't. Perhaps if I get a U3 capable USB-A adapter, maybe that will work. I'm not really sure because I'm not able to reproduce the error at the moment, everything seems to be copying OK, even copying a video that had been giving me trouble to a UHS-III MicroSD in the SD slot. I will check back here later and report.

Jul 8, 2022 10:33 PM in response to Steve_Agnew_NZ

Part of what I said above is not actually correct, I am sorry to say, because I was having trouble copying uncorrupted to an external 2.5" SSD, and there should have been no problem there. And I have to say that another thing I said (I cannot now delete that comment) was also incorrect. The file I was able to successfully copy was actually not the same file that was giving me trouble yesterday. So I'll try to figure this thing out by tomorrow and update. Sorry for the confusion.

Jul 8, 2022 10:52 PM in response to macsnotgnu

Sorry to say that the stuff I said about U3 being UHS-III is rubbish too. U3 is the speed class. NOt sure what UHS-class my SD cards are, but they are SAmsung EVO and say XC I on them. Possibly UHS-I, yet I thought that I tried to buy UHS-III. I will try to double check my facts next time before posting.

Jul 9, 2022 5:04 PM in response to Steve_Agnew_NZ

I have this problem too. The destination is (and always has been) an Intel Mac Mini; the method is my home WiFi; just the source has changed from Intel iMac to Mac Mini M1 running Monterey, and that's when the problem started. It is, though, sporadic: shortly after proving the issue with shasum -a 512 to generate and compare hashes, they started to match again, but today the problem has returned and my media is 'glitchy'.

DG001

Level 1

8 points

Jul 21, 2022 6:54 AM in response to Steve_Agnew_NZ

I'm definitely following this issue. I'm having the same problem. My regular scenario for years was moving files downloaded onto my Mac over to a network drive used by Plex. My family started complaining a couple months ago that videos were glitchy and I spent an embarrassing amount of time trying to figure out why. First maybe was it an issue with Plex but that wasn't it because playing the files directly off the drive without Plex Media Player would have the same glitches in the same place.

Ultimately, I did what you did which was to compare the hex in both files from my local drive on Mac to the network files (even though they were exactly the same size to the byte) and it was a mess. So the problem is exactly what you are describing with copying files from my local drive to network drive -- but mostly really big video files.

My temporary fix has been to download the files directly to the networked drive from my Mac without dealing with Finder. That has cleared everything up but it's a workaround to a silly problem.

Jul 24, 2022 4:14 PM in response to Steve_Agnew_NZ

I also have this problem... I am copying a file from an attached SSD (APFS format) using an ethernet connection to a Synology NAS (formatted BRFS). The file is OK on the source SSD, and is somehow corrupted by the finder copying from location to location. This is BASIC stuff, a file copy should work. I am so glad that I'm not crazy and other people are having the same issue. If it helps I am copying large MKV files. The original is playable, the destination copy is broken (using MPV) and of course the checksums are different. It would seem that something as basic as copying a file could be accomplished in ANY OS without corruption (using 12.4 was also happening with 12.3)

Jul 26, 2022 1:31 AM in response to Toby_Manila

So weirdly I was going to test this using a variety of copy techniques, but today the Finder copy worked just fine (Monterey 12.5). Has anyone seen that it's fixed... or maybe I was just lucky this time?

DG001

Level 1

8 points

Jul 26, 2022 6:35 AM in response to Matt Whiting

I'd test it more often but I find it such a pain to make sure Finder copied it perfectly. For me, it only happens with large video files.

Any recommendations for a free app that could compare two files easily? I'm terrible with Terminal commands so any easy GUI recommendations would be great.

My temporary solution above is causing me all sorts of issues. When I downloads files from my Mac directly to the network drive it gets cut off and stalls the computer all the time. Such a pain. I'll stay on the lookout for this fix. Perhaps a better temporary solutions would be to dust off my old PC and use that for downloading files for now...ugh.

Jul 28, 2022 8:39 PM in response to Matt Whiting

I have tested this under Monterey 12.5 and I can verify that it is NOT fixed. It is still trashing files while they are being copied... does anyone have a way to get Apple to pay attention to this. I would think it is a pretty major bug in an OS to not be able to copy a file reliably.

DG001

Level 1

8 points

Jul 29, 2022 1:45 AM in response to frankthewanderer

I have been using the free open source muCommander to copy files and it's been working perfectly (it's a bit clunky though). It's an alternative to Finder. I'll keep posting here and keeping an eye out until this bug is fixed. I'd much rather use Finder.

File this under Weird: In Monterey copying a file with Finder corrupts the data in the target file