Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'cpmac, mvmac' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
cpmac, mvmac
Authored by: martinx on Apr 24, '03 01:39:32PM

I don't understand why the functionality of moving the whole file
(including resources) isn't directly a part of mv/cp. I mean, I understand
why just porting the unix utilities might result in this situation.

(Well actually I can't understand why mv would even be affected - isn't
moving a file just shuttling its inode to another directory? how would
that affect or cause the resource fork to get lost?)

But under what situation would you want to copy or move a file and lose
the HFS+ specific data? Is there any good reason to not link mv to
mvmac and cp to cpmac? Why didn't Apple do this?



[ Reply to This | # ]
man mv
Authored by: jecwobble on Apr 24, '03 04:14:09PM
This is from the mv man page:
     As the rename(2) call does not work across file systems, mv uses cp(1)
     and rm(1) to accomplish the move.  The effect is equivalent to:

           rm -f destination_path && \
           cp -PRp source_file destination && \
           rm -rf source_file



[ Reply to This | # ]
man mv
Authored by: martinx on Apr 24, '03 05:23:58PM

Right, but MvMac doesn't move files across volumes/filesystems anyway.
The particular question is why MvMac is needed to move files on the
same HFS+ filesystem.



[ Reply to This | # ]
inodes must be changed on same disk mv'ing
Authored by: ylon on Apr 25, '03 06:29:11PM

That's odd. In this case I don't believe the man page. You'll
notice a serious time differential when comparing `cp -fr` with
`mv`. In the case of moving across file systems/networks, this
is true, however when moving on the same disk, it must be
changing inodes. I guess it's time to pull out the source...



[ Reply to This | # ]