Since the comments have clarified your goal - I think you don't have an easy "fix". Here's what I can show that the calls are not equivalent for my initial testing on macOS Ventura 13.0.1.
sudo fs_usage | egrep "mv|Finder"
You'll see a lot of Finder chatter and also some non mv
related items since my grep
is basic. I used uuidgen
to dump a UUID to a file named foo and used Finder and mv to move it to my home folder and then back to tmp.
Finder maps the file in memory and uses other file API mv
calls traditional seek/rename API. Reverse engineering this is totally possible, but you'd need tools or training and time.
12:16:13 ioctl 0.000001 mv
12:16:13 stat64 private/tmp 0.000026 mv
12:16:13 lstat64 /Users/me/foo 0.000027 mv
12:16:13 lstat64 /tmp 0.000010 mv
12:16:13 stat64 /Users/me/foo 0.000008 mv
12:16:13 stat64 private/tmp/foo 0.000013 mv
12:16:13 access private/tmp/foo 0.000010 mv
12:16:13 rename /Users/me/foo 0.000230 mv
12:16:13 exit 0.000017 mv
compared to
12:16:04 fsgetpath /private/tmp 0.000075 Finder
12:16:04 fsgetpath / 0.000057 Finder
12:16:04 fsgetpath /private 0.000018 Finder
12:16:04 fsgetpath /private/tmp 0.000014 Finder
12:16:04 fsgetpath /private/tmp 0.000029 Finder
12:16:04 fsgetpath /Users/me 0.000045 Finder
12:16:04 fsgetpath / 0.000038 Finder
12:16:04 fsgetpath /Users 0.000012 Finder
12:16:04 fsgetpath /Users/me 0.000007 Finder
12:16:04 fsgetpath /Users/me 0.000012 Finder
12:16:04 WrData[ST2] me/Library/Saved Application State/com.apple.finder.savedState/window_18.data 0.000434 W Finder
12:16:04 ftruncate 0.000716 Finder
12:16:04 mmap 0.000120 Finder
12:16:04 PAGE_IN_FILE 0.000079 Finder
12:16:04 fsetxattr 0.000168 Finder
12:16:04 lseek 0.000010 Finder
12:16:04 RdData[SNT2] rs/me/Library/Saved Application State/com.apple.finder.savedState/data.data. 0.000216 W Finder
12:16:04 writev 0.000435 Finder
12:16:04 pwrite 0.000027 Finder
12:16:04 ftruncate 0.000027 Finder
12:16:04 ftruncate 0.000327 Finder
12:16:04 mmap 0.000107 Finder
12:16:04 fsetxattr 0.000181 Finder
Whether either of these is fundamentally different once the operation is complete is challenging to generalize (or at least isn't simple to me yet).
mv
and then assuming that the filesystem in play is APFS with Ownership enabled? – bmike Nov 16 '22 at 14:11cp
? - you may have to reverse engineer things to get that level of detail. There's quite a lot going on with APFS / sparse files, copy on write, shared data on disk - https://eclecticlight.co/2021/07/30/why-nothing-else-can-back-up-to-apfs-like-time-machine-does/ so I was willing to offer an answer if you had something that could be answered in a short post. – bmike Nov 16 '22 at 14:44mv
or thecp
commands with files|folders is if you are transferring many thousands or even millions of files|folders. The Finder adds a tremendous amount of processing overhead when faced with extraordinary moving or copying which is mitigated when you use these commands. You can also pipe the result of themv
orcp
commands into a log file for future examination to make sure things were moved or copied as expected. – IconDaemon Nov 16 '22 at 14:45rsync
to automatically work around a lot of syncing issues automatically. – nohillside Nov 16 '22 at 14:54cp
is not relevant for me, and of course reverse-engineering is an option, but maybe there's some known information, knowledge, documentation, specifications that allow us to avoid that. For example, in macOS's Shortcuts program, we have the "Move File" command - how to know if I can trust it to be like the Finder's one? – Cocktail Nov 16 '22 at 17:54mv
instead of manual dragging in GUI – Cocktail Nov 16 '22 at 17:57