|
|
more /rsrc info
The /rsrc convention has been used all along in OS X and is not dependent on the developer's tools. Anyone with a BSD install can type ls -l */rsrc and see the (normally hidden) resource forks, or ls -l * */rsrc to see the visible data files with their accompanying resource fork, if any.
more /rsrc info
I have been caught by this before - using cp and losing the resource info. So are there any inherent issues in aliasing or soft-linking cp and mv to CpMac and MvMac so that they are always used in preference to /bin/cp and /bin/mv?
more /rsrc info
beware! CpMac and MvMac seem to be deprecated tools with no docs and very wonky results.
more /rsrc info
Yes- CpMac and MvMac are useful, but beware of using them with a -r switch on directory copying / moving. They will make all dot files you've moved visible at the destination. So soft linking them to cp and mv, is not a good idea! Better to use these cl tools on individual files, that you know will have resource forks (an example would be files that open in classic only applications, such as Quark.)
more /rsrc info
note that foo/rsrc is obsolete and might go away in the future, the official [1] way to access forked files in HFS+ is via foo/..namedfork/forkname, most files only have foo/..namedfork/data and foo/..namedfork/rsrc, but HFS+ supports an unlimited number of named forks, which can be created using the FSCreateResourceFile Carbon API [2].
|
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.32 seconds |
|