[CMake] CPack Bundle Generator easily hits hdiutil MNAMELEN limit

[David Cole]

hdiutil attach "blah.dmg"

should be sufficient without specifying *any* mount point at all.

The output of hdiutil attach gives you the name of the folder in "/Volumes"
where the *.dmg file was mounted.

Therefore, simply capture the output of the hdiutil command and analyze it
to get the path where the thing got mounted rather than demanding that it be
mounted in a given spot. That way, the OS (via hdiutil) decides when it
needs to worry about duplicate names and all that jazz. Following is a
sequence of commands to open up the cmake-2.6.2 *.dmg file and the resulting
output of two separate hdiutil attach commands on two separate (but
identically named) *.dmg files.

*Using this technique* would be an acceptable patch to fix the bug. CPack is
not going to provide a tmp file name API and wanting to mount a *.dmg file
is not a reasonable thing to do in an arbitrary CMake build tree (because of
the stupid 90 character limit). Sorry I do not presently have time to work
on such a patch in the near term.... but if one were to appear (that
analyzes hdiutil output instead of forcing a -mountroot argument) then it
would have a higher likelihood of being applied.


HTH,
David


hdiutil experiment: (Mac OSX 10.5 -- should be verified on 10.4 and earlier,
also...)

[in ~/Downloads]
$ hdiutil attach ./cmake-2.6.2-Darwin-universal.dmg
expected   CRC32 $31C5BA6B
/dev/disk1              Apple_partition_scheme
/dev/disk1s1            Apple_partition_map
/dev/disk1s2            Apple_HFS
/Volumes/cmake-2.6.2-Darwin-universal

$ cd ..

[now in ~]
$ cp Downloads/cmake-2.6.2-Darwin-universal.dmg .

$ hdiutil attach ./cmake-2.6.2-Darwin-universal.dmg
... [blah blah blah snipped out]...
verified   CRC32 $31C5BA6B
/dev/disk2              Apple_partition_scheme
/dev/disk2s1            Apple_partition_map
/dev/disk2s2            Apple_HFS
/Volumes/cmake-2.6.2-Darwin-universal 1

$ ls -la /Volumes
total 8
drwxrwxrwt@  5 root       admin   170 Jan  7 15:03 .
drwxr-xr-x  37 davidcole  staff  1326 Dec 27 13:37 ..
lrwxr-xr-x   1 root       admin     1 Jan  5 09:15 Macintosh HD -> /
drwxr-xr-x   6 davidcole  staff   238 Sep 24 14:32
cmake-2.6.2-Darwin-universal
drwxr-xr-x   6 davidcole  staff   238 Sep 24 14:32
cmake-2.6.2-Darwin-universal 1




On Wed, Jan 7, 2009 at 2:24 PM, Michael Jackson <mike.jackson at bluequartz.net
> wrote:

>
>
> On Jan 7, 2009, at 1:42 PM, Bill Hoffman wrote:
>
>  Mike Arthur wrote:
>>
>>> From the hdiutil manpage:
>>>>
>>> -mountroot path mount volumes in path instead of in /Volumes.  path must
>>> exist.  Note that mountpoint paths must be less than MNAMELEN characters (90
>>> as of this writing).
>>> This limit is easily hit by the mounting of the temporary dmg (tmp.dmg)
>>> in the Bundle Generator and causes it to fail.
>>> May I suggest that, instead of mounting into ./_CPack_Packages/OSX-
>>> Universal/Bundle/mnt/ instead /tmp/cpackmnt/ is used instead or the
>>> mountpoint parameter omitted and the Volumes mountpoint is used instead?
>>> I can write a patch if necessary but it should be a trivial fix (if
>>> agreed).
>>>
>>
>> I am concerned that /tmp/ would not be unique enough, what if two cpacks
>> run at the same time?
>>
>> -Bill
>>
>
>
> My vote is for /Volumes since that is where OS X mounts everything else and
> is the expected behavior for mounting disk images on OS X.
>
> As far as duplicate names go in /Volumes there must some sort of API
> because I mount USB multiple thumb drives all the time and each has the name
> "UNTITLED" but yet they all mount.
>
> There is also the option:
>
> -mountrandom path  like -mountroot, but mountpoint names are randomized
> with mkdtemp(3).  Note that mountpoint paths must be less than MNAMELEN
> characters (90 as of this writing).
>
> Which would probably just solve the problem in combination with mounting in
> /Volumes.
>
> Just my 2 cents.
>
> ---
> Mike Jackson                 www.bluequartz.net
>
>
>
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090107/fd82fc3d/attachment.htm>