|
|
Resource forks ?
I hate to be a wet blanket but this script appears to use "mv" to do it's business. This will happily hose the resource forks of any files therein. I suggest rev. 2 should use "ditto" if you want to avoid this (been there, done that with my adduser scripts).
Resource forks ?
"mv" only affects resource forks if you're actually copying files -- for example, if you're moving files between volumes. When used on the same volume, all "mv" does is update a file's directory entry with the new path/name of the file.
In other words, if you were creating a script to move a user's home directory to another volume, it would be an issue. But for this purpose, "mv" is appropriate.
Resource forks ?
Yup, probably true, but this always made me a little nervous. And I have read about claims to the contrary although I guess this should not be possible. It seemed like I had a resource fork issue with mv once but in my haste I couldn't stop and verify it. I would say ditto would be the preferred way anyway (just in case) but are Dev tools required for ditto to be present? Of course all of a sudden you need more free space conceivably and the process could be a lot slower.
Resource forks ?
The problem with using "ditto" in this scenario is that you really don't want to copy files, or even "move" them; you simply want to change the pathname of the home directory.
If you were to use ditto, you'd basically be creating copies of everything -- you'd end up with two copies, and you'd later have to go through and delete the originals. "mv" simply keeps everything exactly where it is on the drive, but changes the logical path to those files. So for the example of changing a short username, after changing the name you want your home directory to have the same name as your new username. A "mv" command is the safest way to do this.
Resource forks ?
Greetings, As the co-author of the ChangeShortName utility, I can assure you that mv is perfectly safe and appropriate in this context. First of all, mv preserves all resource fork and meta-data information when used to move or rename directory entries on the same logical device. mv only has problems with resource forks when asked to move a file from one logical device to another, in which case it switches to its 'cp' mode where is actually copies that file. In this mode, it uses the same code to copy the file as cp, with all of the attendant problems. The ChangeShortName script (a) doesn't copy anything, and (b) doesn't move anything with resource forks or meta-data. It renames the user's home directory, keychain, crontab, Samba shares, and http configurations; None of which will cause any files to be copied. It does make working copies of the httpd config files and the NetInfo database in /tmp. But these files should always be on the same volume as the source, so no copy would ever occur. Even if the user has done something radical, like relocated their /tmp directory to another volume, it's still harmless because none of these files contain any resource or meta-data information. They are all simple, flat, UNIX files which mv can copy without any problems. |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks 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.05 seconds |
|