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


Click here to return to the 'Resource forks ?' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Resource forks ?
Authored by: ssevenup on May 28, '04 07:42:14PM

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).

--MM


---
Mark Moorcroft
ELORET Corp. - NASA/Ames RC
Sys. Admin.



[ Reply to This | # ]
Resource forks ?
Authored by: DanFrakes on May 28, '04 10:03:30PM
"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.

[ Reply to This | # ]

Resource forks ?
Authored by: ssevenup on May 28, '04 10:48:03PM

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.

--MM

---
Mark Moorcroft
ELORET Corp. - NASA/Ames RC
Sys. Admin.



[ Reply to This | # ]
Resource forks ?
Authored by: DanFrakes on May 28, '04 11:26:57PM
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.

[ Reply to This | # ]

Resource forks ?
Authored by: JBucanek on May 29, '04 10:57:22AM

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.

Please contact Dan or I if you have any questions.



[ Reply to This | # ]