Page MenuHomeFreeBSD

apply same fix to cp(1) as mv(1) when copying to filesystems that do not support file flags
Needs ReviewPublic

Authored by sigsys_gmail.com on Sep 26 2018, 12:26 AM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

mv and cp error out when copying directories to filesystems that do not support file flags and some of the source files have flags set. The copying is still done correctly, but they print error messages and exit with a non-successful status.

The main problem to me is that if mv was used to move a directory, the source directory will not be deleted after the copy because the copying will be treated as if it had failed.

And, if you use ZFS locally, a lot of your files will have the "uarch" flag. Because ZFS sets it automatically. If you try to move those files to an NFS mount point, you'll get errors, and mv won't actually "move" your files, only copy them. Which is annoying because this flag is intended to be managed automatically and is arguably not very important, and I'm not even sure if you can disable it. This problem also happens with other filesystems that do not support file flags (or at least the uarch file flag), like ext2fs. msdosfs works because it maps uarch to some native attribute interestingly enough.

mv sometimes does the copying itself instead of calling cp (when no recursion is necessary), and it has a workaround for this problem. cp however does not have the workaround. So the problem manifests itself when trying to move directories.

So, this patch replicates mv's fix into cp. The logic should be the same.

It's debatable if that's the best way to handle the situation (there are some caveats in mv's comments), but it fixes the problem, and it makes both mv and cp consistent.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped