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


Click here to return to the 'Script has some bugs' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Script has some bugs
Authored by: Jayce on Mar 12, '02 01:17:34AM

There is some problems in the script :
- The use of cp instead of ditto implies losing resource-forks.
- the SIZE calculated from the size of the folder is not good. SIZE must be the size of the folder + x Mo. The more the folder is big, the more x must be big. (it's for catalog informations).
- The name of the disk linked to the dmg is not always $VOL. The only sure way to get the name of the volume is to use the -verbose option of hdiutil and to grep the result.



[ Reply to This | # ]
Script has some bugs
Authored by: sharumpe on Mar 12, '02 11:31:30AM

Good point (both of you) about ditto - I will hem/haw a bit by saying that I didn't write the original. ;)

However, in looking at the ditto man page to try to use it instead, it looks like it has to be run as root. I don't want to be responsible for people who don't normally use root enabling it just for this. ;) If you know enough to use root safely, you can make the change from cp to ditto. Here's my compromise: NOTE: THIS DOES NOT COPY RESOURCE FORKS! <grin>

As far as the size goes, right now it takes the size reported by du -sk. I get what you're saying (before it had a static 5MB size) but I'm not aware of a command that will give me that information. We're probably stuck with a guesstimate. I've increased the 'fudge factor,' currently at 1MB, to 3MB in my copy.

It took me a bit to figure out what you were getting at with $VOL, but if I understand correctly, the reason that $VOL will not always be correct is that the system will sometimes give you foo-1 if foo is already mounted, correct? In that case, how do you know which one you want? It could be the last one, but that's not necessarily going to be the case. :)

In any case, the script is a good starting point, and illustrates one of the cool things that can happen when you bring Unix to the Mac OS.

Mr. Sharumpe



[ Reply to This | # ]
Script has some bugs
Authored by: a1291762 on Mar 12, '02 04:55:20PM

Ditto has to run as root?

Is it a simple Unix executable?

You could do this to make it run as root easily:
sudo chown root.admin ditto
sudo chmod 4755 ditto

This makes it owned by root and group admin. The 4755 makes it setuid and executable. Thus anyone can run it *without* having to use sudo and it will automatically gain root privilages.

I'll go look at the ditto page and suggest this to the author I think...



[ Reply to This | # ]
D'oh!
Authored by: a1291762 on Mar 12, '02 05:27:30PM

D'oh! I just looked at an OS X system...

I didn't realise ditto was an Apple supplied command :)

I just tried the setuid bit and it works except for one small thing... It creates the destination file as root.

So if you do "ditto foo bar" then bar is owned by root and you'll need to sudo chown <yourname>.[admin|staff] and possibly reset the permissions on it.

Oh well... maybe a wrapper program could sort that out...



[ Reply to This | # ]
Script has some bugs
Authored by: sharumpe on Mar 13, '02 01:34:41AM

It is generally a bad idea to run anything as root, and even less of a good idea to set programs to setuid. If the program turns out to have some sort of problem, it may become possible to gain root access.

Not to mention, of course, little things like the fact that the files are created as root. cp has a flag that maintains permissions, I wonder if ditto does?

Mr. Sharumpe



[ Reply to This | # ]
Ditto does _not_ have to run as root
Authored by: sabi on Mar 13, '02 03:54:51AM

The man page is out of date. I've reported this bug (such as it is) to
Apple, they've fixed it already.

Ditto is a wonderful tool since it's the only one that supports
duplicating including metadata, preserving modification dates,
symbolic links, etc. It cuts across the Mac and Unix sides perfectly.



[ Reply to This | # ]
Script has some bugs
Authored by: Jayce on Mar 17, '02 01:48:05AM

>However, in looking at the ditto man page to try to use it instead, it looks >like it has to be run as root.

You didn't need root privileges to use ditto... You only need root privileges to copy the system tree...

>As far as the size goes, right now it takes the size reported by du -sk. I get >what you're saying (before it had a static 5MB size) but I'm not aware of a >command that will give me that information. We're probably stuck with a >guesstimate. I've increased the 'fudge factor,' currently at 1MB, to 3MB in my >copy.

I had a problem with this with a script of mine... And, the only solution I had found is to make my diskimage 20% larger of my folder... Here is the command :
sudo hdiutil create -sectors $(expr $(echo $(sudo du -sHx "$Folder")|cut -f1 -d' ') * 12 / 10) $ImageFile

>It took me a bit to figure out what you were getting at with $VOL, but if I >understand correctly, the reason that $VOL will not always be correct is that >the system will sometimes give you foo-1 if foo is already mounted, correct? In >that case, how do you know which one you want? It could be the last one, but >that's not necessarily going to be the case. :)

The only way is to use hdiutil to mount the image :
MOUNT_POINT=$(sudo hdiutil mount -verbose $ImageFile | grep "/Volumes" |sed -e "s#</{0,1}string>##g")

>In any case, the script is a good starting point, and illustrates one of the >cool things that can happen when you bring Unix to the Mac OS.

Sure, it is a good start...



[ Reply to This | # ]