CP gets weird trying to pull from NTFS
by kires from LinuxQuestions.org on (#4X8WH)
I've just migrated my desktop from windows 7 to Ubuntu 19.10 and I'm not entirely sure what the hell I'm doing, so please let me know if this question needs to go to the newbie forum or somewhere else.
Most of my stored music and videos are backed up onto a new 8 TB drive (formatted with NTFS because oops) When I copied them over to their new home on the RAID5 array I managed to get working via mdadm, I got permissions errors on some of them, like say maybe 1/3 of them. The weird part is that the destination files are created, but empty. So all the copies that fail for permissions reasons actually create zero-byte versions of themselves. This sucks because it makes it a lot harder to identify the ones that didn't come across so I can try to deal with them specifically. I did some futzing about with mount options in fstab, and I was able to get Jesus (that's the name of the backup drive) to allegedly accept ownership and permissions changes after a few reboots, so all contents are now allegedly owned by me, and have perms of 777. I say allegedly because this made no difference to either the permissions error, or the behavior I'm crying about here.
I did some testing from other partitions, and cp doesn't do this when failing for permissions reasons from another xfs or FAT partition, just from this ntfs one. I didn't create another ntfs partition to test. I've also done some digging about, here and elsewhere on the internet, but I'm not finding this specific problem.
So, my question:
Is there some way I can get cp to NOT create empty versions of files when the copy fails coming from this NTFS partition?
Or better yet, are there some mount options I can try that will resolve the issue? Here's the mount options I've come up with so far.
Code:UUID=2666045F660431DB /tank auto ntfs-3g,permissions,users,exec 0 0FWIW, I suspect that the permissions error it's throwing might be a lie, and it's just saying that because it doesn't know how to explain what's actually gone sideways. Thank you for any help or advice you can provide.
PS- It's a fresh install of Ubuntu 19.10, with all packages updated.
Most of my stored music and videos are backed up onto a new 8 TB drive (formatted with NTFS because oops) When I copied them over to their new home on the RAID5 array I managed to get working via mdadm, I got permissions errors on some of them, like say maybe 1/3 of them. The weird part is that the destination files are created, but empty. So all the copies that fail for permissions reasons actually create zero-byte versions of themselves. This sucks because it makes it a lot harder to identify the ones that didn't come across so I can try to deal with them specifically. I did some futzing about with mount options in fstab, and I was able to get Jesus (that's the name of the backup drive) to allegedly accept ownership and permissions changes after a few reboots, so all contents are now allegedly owned by me, and have perms of 777. I say allegedly because this made no difference to either the permissions error, or the behavior I'm crying about here.
I did some testing from other partitions, and cp doesn't do this when failing for permissions reasons from another xfs or FAT partition, just from this ntfs one. I didn't create another ntfs partition to test. I've also done some digging about, here and elsewhere on the internet, but I'm not finding this specific problem.
So, my question:
Is there some way I can get cp to NOT create empty versions of files when the copy fails coming from this NTFS partition?
Or better yet, are there some mount options I can try that will resolve the issue? Here's the mount options I've come up with so far.
Code:UUID=2666045F660431DB /tank auto ntfs-3g,permissions,users,exec 0 0FWIW, I suspect that the permissions error it's throwing might be a lie, and it's just saying that because it doesn't know how to explain what's actually gone sideways. Thank you for any help or advice you can provide.
PS- It's a fresh install of Ubuntu 19.10, with all packages updated.