[iwicked]

Hi all. I’m using M1 Mac with Big Sur with Paragon NTFS to mount NTFS hard drives.

So I am transferring tons of video files and images from one Seagate drive (NTFS) to another (HFS+). Basically I’m planning to format the NTFS drive and convert to HFS+ which is why I’m backing everything up.

Now after copy pasting files I notice that in some of the folders the video and image files have incorrect thumbnails. Basically the thumbnails being displayed belong to other files. The files show the correct size and play fine. I copy paste to my internal drive then the thumbnails are fixed. I then copy paste those back to the external HDD.

Also, I have many of the files tagged in Finder. When I search with the tag, the finder shows wrong file types under the tag. I am trying to figure out whether this is an issue with my Finder or external hard drives. Please note that when I deleted the quicklook cache file, the incorrect thumbnails are fixed. But tagged files are still not showing up correctly.

I’m getting concerned with this weird behaviour. Does this mean that the hard disk is failing? Then which one - the one where I’m copying stuff from or the one where I’m pasting the files? Or is it some other issue? Please help me out as I just can't figure out where the problem is. Thanks!

[Trees]

If not already, suggest contacting Paragon Support. Based upon your thorough analysis above sounds like maybe file system metadata, indexing, or symbolic links could be potential areas. The problem(s) could be with Paragon NTFS, MacOS Big Sur or both; or something else. I could be completely wrong, thus the suggestion to contact Paragon Support as a first step.

[Ed7789]

Hi all. I’m using M1 Mac with Big Sur with Paragon NTFS to mount NTFS hard drives.

So I am transferring tons of video files and images from one Seagate drive (NTFS) to another (HFS+). Basically I’m planning to format the NTFS drive and convert to HFS+ which is why I’m backing everything up.

Now after copy pasting files I notice that in some of the folders the video and image files have incorrect thumbnails. Basically the thumbnails being displayed belong to other files. The files show the correct size and play fine. I copy paste to my internal drive then the thumbnails are fixed. I then copy paste those back to the external HDD.

Also, I have many of the files tagged in Finder. When I search with the tag, the finder shows wrong file types under the tag. I am trying to figure out whether this is an issue with my Finder or external hard drives. Please note that when I deleted the quicklook cache file, the incorrect thumbnails are fixed. But tagged files are still not showing up correctly.

I’m getting concerned with this weird behaviour. Does this mean that the hard disk is failing? Then which one - the one where I’m copying stuff from or the one where I’m pasting the files? Or is it some other issue? Please help me out as I just can't figure out where the problem is. Thanks!

Have you tried to do a checksum on the files from your NTFS drive and your HFS+ drive? If the two checksums are identical, the two files should be identical.
While it is possible for two completely different files to have the same checksum, it is extremely unlikely. There are 2^112 different values if you use SHA-2 (in SHA-224 mode).

Like @Trees suggested, contact Paragon's support team. They might have compatibility issues with Apple Silicon computers, as those are very recent and different from Intel devices.

[iwicked]

If not already, suggest contacting Paragon Support. Based upon your thorough analysis above sounds like maybe file system metadata, indexing, or symbolic links could be potential areas. The problem(s) could be with Paragon NTFS, MacOS Big Sur or both; or something else. I could be completely wrong, thus the suggestion to contact Paragon Support as a first step.

Thanks for the suggestion - I will contact Paragon Support. But does it look like the hard drives are ok? That's what I am scared of most. One of the drives is almost brand new, purchased 2 months back. Whenever I try to eject the HFS+ drive it shows the error message "drive is in use.." but it does get ejected. I am guessing Finder is running some process in the background. Anyway I can see what's up with that?

Will ejecting like this corrupt the files? It is worth mentioning that the problems started when I first started cutting and pasting files between the drives. I noticed that few of the files were corrupted and wouldn't run. So I ran couple of data recovery softwares and recovered most of the files. But that's when I noticed that the thumbnails started getting messed up.

[iwicked]

Have you tried to do a checksum on the files from your NTFS drive and your HFS+ drive? If the two checksums are identical, the two files should be identical.
While it is possible for two completely different files to have the same checksum, it is extremely unlikely. There are 2^112 different values if you use SHA-2 (in SHA-224 mode).

Like @Trees suggested, contact Paragon's support team. They might have compatibility issues with Apple Silicon computers, as those are very recent and different from Intel devices.

How do I do a checksum? I have never done it before so can you please advise how to do that. Also, if I try copy pasting the files will it somehow lead to more corruption of the source or copied files? I guess I'm thinking like it's some infectious disease going around corrupting the thumbnails, so what if it starts rendering the files completely unusable! Sorry if I sound silly but these are precious memories in the drive I am trying to preserve.

[doogald]

Now after copy pasting files I notice that in some of the folders the video and image files have incorrect thumbnails. Basically the thumbnails being displayed belong to other files. The files show the correct size and play fine. I copy paste to my internal drive then the thumbnails are fixed. I then copy paste those back to the external HDD.
....

I’m getting concerned with this weird behaviour. Does this mean that the hard disk is failing? Then which one - the one where I’m copying stuff from or the one where I’m pasting the files? Or is it some other issue? Please help me out as I just can't figure out where the problem is. Thanks!

I don't think so. If I was to venture a guess, I would guess this is just because NTFS is not a native format for MacOS and the Quicklook cache process that creates the thumbnails is getting "confused" as it processes the files; it's more likely an issue with the Paragon NTFS service.

If there is a way to transfer from NTFS to a FAT32 drive on a Windows system, and then go to HFS+ on a Mac from the FAT32, that might be better.

[iwicked]

I don't think so. If I was to venture a guess, I would guess this is just because NTFS is not a native format for MacOS and the Quicklook cache process that creates the thumbnails is getting "confused" as it processes the files; it's more likely an issue with the Paragon NTFS service.

If there is a way to transfer from NTFS to a FAT32 drive on a Windows system, and then go to HFS+ on a Mac from the FAT32, that might be better.

This certainly makes me feel better. I am also leaning towards issues with NTFS and HFS+ through Paragon. I have contacted Paragon support. Unfortunately the FAT32 isn't an option.

One more thing, every time I try to eject the HFS+ drive I get this error "Failed to unmount “drive” because it is currently in use." It does eject after this. Any idea why this is happening?

[Ed7789]

I’m sorry for this lengthy reply… I wanted to provide you a detailed explanation of the commands you would be typing so that you know what’s going on.

They say knowledge is power.

Will ejecting like this corrupt the files?

No. If Finder refuses to eject a drive, it’s because something is doing an access operation on a directory or file. The system will allow the operation to finish before dismounting the volume.

Now, if you choose to do a Force Eject, then data corruption can occur, because you’re asking the computer to not care about what it is doing. A Force Eject will be offered only if it’s not able to dismount the volume after a few seconds.

How do I do a checksum? I have never done it before so can you please advise how to do that. Also, if I try copy pasting the files will it somehow lead to more corruption of the source or copied files? I guess I'm thinking like it's some infectious disease going around corrupting the thumbnails, so what if it starts rendering the files completely unusable! Sorry if I sound silly but these are precious memories in the drive I am trying to preserve.

A quick suggestion: Have you considered transferring your files over a network connection (either wireless, wired or any combination of the two)? It will eliminate your dependency on third-party software.

Risks of storing files: I don’t want to scare anyone, any action taken on a drive can be risky, including simply using it and not using it. A drive can fail at any time, so you should always have multiple backup copies of your data, in multiple locations.

Checksums:
To create a checksum file, you would use these two commands in the Terminal app (be patient, as these will take time to run):

cd /Path/to/your/folder 
find . -type f -exec shasum -a 512 -b {} \; > ~/sha512sums

To compare your destination folder against the checksums:

cd /Path/to/your/folder
shasum -c ~/sha512sums

The easiest way to get /Path/to/your/folder is to take the drive or folder in Finder’s main section, and drag it into the Terminal window (section highlighted in red in the screenshot); macOS will fill the path in. Alternatively, you can take the title bar’s icon (just hover over the name for a few seconds) and drag it onto the Terminal window (yellow arrow).


If the files are mathematically identical, the command will print the name of the file followed by OK (similar to the screenshot below). Otherwise, you will have a FAILED.




Explainer of what these commands and parameters mean

• cd: Change directory, with the directory we want to change to as a parameter.
• find: Find something, based on the parameters provided to the command.
  
  • .: Stands for the current directory
  • -type: The type of content we are searching for (f stands for file, d would be directories).
  • -exec: Execute the following command on the files you find—I go onto details for shasum below—where {} is replaced by the file name and \; ends the command statement.
  
  
• > ~/sha512sums: > is the pipe character. This will redirect the regular output of the preceding command to a file. Here ~/sha512sums.
  
  • ~: The tilde stands for your user directory.
  • WARNING: The regular pipe will overwrite any contents in the destination file. There is no confirmation before overwriting. Make sure the file does not exist first.
  
  
• shasum: This command—AFAIK specific to macOS, although similar apps exist for Linux and Windows—calculates and checks checksums using the SHA series of hash algorithms.
  
  • -a 512: The algorithm to use to calculate the SHA checksums. I selected the SHA-512 hash, as it provides the least risk of collision (to the magnitude of 2^256), but it is slower to run; others do exist.
  • -b: Run the files in binary mode. Text files are formatted differently between classic MacOS (MacOS 9 or earlier), macOS and Windows; this should avoid that.
  • -c ~/sha512sums: Compare the checksums from the file ~/sha512sums with the files in the current directory.

You can always get the full system documentation for a command—with some exceptions—by running:

man COMMAND

[iwicked]

I’m sorry for this lengthy reply… I wanted to provide you a detailed explanation of the commands you would be typing so that you know what’s going on.

They say knowledge is power.


No. If Finder refuses to eject a drive, it’s because something is doing an access operation on a directory or file. The system will allow the operation to finish before dismounting the volume.

Now, if you choose to do a Force Eject, then data corruption can occur, because you’re asking the computer to not care about what it is doing. A Force Eject will be offered only if it’s not able to dismount the volume after a few seconds.



A quick suggestion: Have you considered transferring your files over a network connection (either wireless, wired or any combination of the two)? It will eliminate your dependency on third-party software.

Risks of storing files: I don’t want to scare anyone, any action taken on a drive can be risky, including simply using it and not using it. A drive can fail at any time, so you should always have multiple backup copies of your data, in multiple locations.

Checksums:
To create a checksum file, you would use these two commands in the Terminal app (be patient, as these will take time to run):

cd /Path/to/your/folder 
find . -type f -exec shasum -a 512 -b {} \; > ~/sha512sums

To compare your destination folder against the checksums:

cd /Path/to/your/folder
shasum -c ~/sha512sums

The easiest way to get /Path/to/your/folder is to take the drive or folder in Finder’s main section, and drag it into the Terminal window (section highlighted in red in the screenshot); macOS will fill the path in. Alternatively, you can take the title bar’s icon (just hover over the name for a few seconds) and drag it onto the Terminal window (yellow arrow).
https://images.moimeme.ca/imore/4416...t 19.34.49.png

If the files are mathematically identical, the command will print the name of the file followed by OK (similar to the screenshot below). Otherwise, you will have a FAILED.
https://images.moimeme.ca/imore/4416...t 19.25.17.png
https://images.moimeme.ca/imore/4416...t 19.31.00.png


Explainer of what these commands and parameters mean

• cd: Change directory, with the directory we want to change to as a parameter.
• find: Find something, based on the parameters provided to the command.
  
  • .: Stands for the current directory
  • -type: The type of content we are searching for (f stands for file, d would be directories).
  • -exec: Execute the following command on the files you find—I go onto details for shasum below—where {} is replaced by the file name and \; ends the command statement.
  
  
• > ~/sha512sums: > is the pipe character. This will redirect the regular output of the preceding command to a file. Here ~/sha512sums.
  
  • ~: The tilde stands for your user directory.
  • WARNING: The regular pipe will overwrite any contents in the destination file. There is no confirmation before overwriting. Make sure the file does not exist first.
  
  
• shasum: This command—AFAIK specific to macOS, although similar apps exist for Linux and Windows—calculates and checks checksums using the SHA series of hash algorithms.
  
  • -a 512: The algorithm to use to calculate the SHA checksums. I selected the SHA-512 hash, as it provides the least risk of collision (to the magnitude of 2^256), but it is slower to run; others do exist.
  • -b: Run the files in binary mode. Text files are formatted differently between classic MacOS (MacOS 9 or earlier), macOS and Windows; this should avoid that.
  • -c ~/sha512sums: Compare the checksums from the file ~/sha512sums with the files in the current directory.

You can always get the full system documentation for a command—with some exceptions—by running:

man COMMAND

Wow! Thank you so much for this detailed response! I really appreciate you taking the time to explain everything - thank you so much for this. To be honest, looking at so many codes I am little lost and nervous.

You warned about this: "The regular pipe will overwrite any contents in the destination file. There is no confirmation before overwriting. Make sure the file does not exist first. "

I am not very clear about this. Does this mean that running this checksum has a risk of overwriting files in the destination folder?

From what I understand, I will have to run this after copying all the files to the destination hard drive so to compare between that and the source.

Thank you for the explanation about force eject. I was getting a little worried. So much so that I have been shutting down my Mac then disconnecting the drive in question to avoid seeing this message and the risk of corruption. I guess I can rest easy now.

I am not sure how I can transfer over a network connection - I'm afraid I am not too tech savvy. What I have been trying today is to copy paste the files from the NTFS drive to my Mac's internal drive, small batches at a time. Then copying from my internal drive to the HFS+ drive. So far this seems to be working fine - no issues with incorrect thumbnails yet. You think this is a good alternative?

But I have not been able to solve the issue regarding the display of incorrect files on the hard drive when I search with tags.

[Ed7789]

You're welcome

You warned about this: "The regular pipe will overwrite any contents in the destination file. There is no confirmation before overwriting. Make sure the file does not exist first. "

I am not very clear about this. Does this mean that running this checksum has a risk of overwriting files in the destination folder?

No. The file name I put in is ~/sha512sums where ~ stands for your user directory - typically in /Users/YourUsername - and sha512sums being the file's name. It would overwrite that specific file.

From what I understand, I will have to run this after copying all the files to the destination hard drive so to compare between that and the source.

Correct

I am not sure how I can transfer over a network connection - I'm afraid I am not too tech savvy. What I have been trying today is to copy paste the files from the NTFS drive to my Mac's internal drive, small batches at a time. Then copying from my internal drive to the HFS+ drive. So far this seems to be working fine - no issues with incorrect thumbnails yet. You think this is a good alternative?

It's one way to achieve what you're trying to do.

But I have not been able to solve the issue regarding the display of incorrect files on the hard drive when I search with tags.

I can't help you there, I have no idea how tags work. I used them exactly twice in 11 years.

[iwicked]

You're welcome


No. The file name I put in is ~/sha512sums where ~ stands for your user directory - typically in /Users/YourUsername - and sha512sums being the file's name. It would overwrite that specific file.


Correct


It's one way to achieve what you're trying to do.


I can't help you there, I have no idea how tags work. I used them exactly twice in 11 years.

Thanks for the response Ed. I had thought copying in small batches from the NTFS external drive to my internal one, then copying from there to the external HFS+ had solved the thumbnail issue.

But just now I noticed the issue is still present. In both the drives, inside random folder I see the thumbnails have gotten messed up. I'm having to go through each of the files one-by-one, identifying the ones with the wrong thumbnails and then copying pasting from the internal drive and back. I really don't know what's causing this error. I am losing so much time like this. It is worth mentioning that the problem is occurring to few specific folders repeatedly in both the drives.

I had thought perhaps it's something to do with Paragon NTFS. That might explain why it's happening in the NTFS drive. But then why is it happening on the HFS+ drive? Mac OS Big Sur should be writing to it natively and there shouldn't be any issues, right?

Any idea what's going on? Some insight would be greatly appreciated.

[Ed7789]

It could very well have something to do with Parangon's software. For all intents and purposes, it's a 3rd party driver that's reading from the hard drive.

If you a second computer with Windows, you could transfer the files between the two computers. You would remove non-bundled drivers from the equation by doing so.

[iwicked]

It could very well have something to do with Parangon's software. For all intents and purposes, it's a 3rd party driver that's reading from the hard drive.

If you a second computer with Windows, you could transfer the files between the two computers. You would remove non-bundled drivers from the equation by doing so.

When I am transferring from my internal drive to HFS+ I disable and quit Paragon. Then it should be writing natively because it's Apple right? Why is the HFSA+ drive showing the issue?

If I use Windows then I wouldn't be able to access HFS+ because it's only Mac. That's again 3rd party driver requirement there

[Ed7789]

When I am transferring from my internal drive to HFS+ I disable and quit Paragon. Then it should be writing natively because it's Apple right? Why is the HFSA+ drive showing the issue?

Not necessarily. The driver could still be loaded and running to access the drive even when Parangon NTFS is exited.

I don’t how their software works internally, so I need to take some general assumptions.

If Apple’s NTFS driver were to take over, you would see the drive eject when Parangon’s software is exited.

If I use Windows then I wouldn't be able to access HFS+ because it's only Mac. That's again 3rd party driver requirement there

The idea is to have the NTFS drive connected on the Windows side, and the HFS+ drive on the macOS side. Then you would use the file sharing (of Remote Login) features to transfer the files.

That way, we’re making sure that bundled code will be handling your files.

[iwicked]

Not necessarily. The driver could still be loaded and running to access the drive even when Parangon NTFS is exited.

I don’t how their software works internally, so I need to take some general assumptions.

If Apple’s NTFS driver were to take over, you would see the drive eject when Parangon’s software is exited.



The idea is to have the NTFS drive connected on the Windows side, and the HFS+ drive on the macOS side. Then you would use the file sharing (of Remote Login) features to transfer the files.

That way, we’re making sure that bundled code will be handling your files.

Thanks for this suggestion. It could work. What if I drop the files in Dropbox in Windows machine and then it syncs with my Mac where it’s also logged in? Will this work?

I don’t have access to a Windows machine at this point. But if the above works then I can try to get one. What if I follow the Dropbox method in the same computer? Like I access the NTFS drive from my Mac and copy to Dropbox. Then I download from Dropbox to the HFS+ drive?

There’s a new problem - the HFS+ drive now disconnects randomly and I get the “not ejected properly” error. I’m going to try with different cables but is this a sign of hard disk issue?

[Ed7789]

Thanks for this suggestion. It could work. What if I drop the files in Dropbox in Windows machine and then it syncs with my Mac where it’s also logged in? Will this work?

I don’t have access to a Windows machine at this point. But if the above works then I can try to get one. What if I follow the Dropbox method in the same computer? Like I access the NTFS drive from my Mac and copy to Dropbox. Then I download from Dropbox to the HFS+ drive?

There’s a new problem - the HFS+ drive now disconnects randomly and I get the “not ejected properly” error. I’m going to try with different cables but is this a sign of hard disk issue?

Dropbox would work for this purpose.

Regarding the drive ejecting abnormally, I would suggest checking that all the cables are secure.

Trying to change USB ports and/or cables might also help.