How difficult it is to make appdmg cross-platform?

[szwacz]

Hello again.

This lib could be intergallactically awesome if dependent only on pure-js node libraries, so it can run on every OS node is running on. How difficult it is to make it this way?
You mentioned previously building .DS_Dtore.
What are the other problems to address?

If this is relatively easy I might be interested in contributing to this effort.

[LinusU]

Information regarding the .DS_Store file format:

• http://en.wikipedia.org/wiki/.DS_Store
• https://wiki.mozilla.org/DS_Store_File_Format

Roadmap:

• Find SetFile replacement

We use SetFile to enable the icon-flag. Using a pure js implementation here would be awesome just in it self since SetFile is distributed with Xcode. This is only necessary for icon-support.

• Find hdiutil replacement

We need to be able to create a dmg file from a folder, this shouldn't be too hard. hdiutil is distributed with vanilla OS X so this is only needed for support of other platforms.

• Find bless replacement

We use the bless command to make sure that the Finder opens the image after mounting it. I would guess that this program really just sets some bits. Should be fairly easy to implement in pure js.

• Generate .DS_Store file

This is, AFAIT, the hardest part. Right now we use apple script to open up the finder, rearrange the icons and set the background. Then sleep for some seconds which makes Finder save the changes to the .DS_Store file.

The best way to do this would is writing the file directly from the program, but we need to figure out how the file format works and what bits and bytes we need to set in order to accomplish the following:

• Set icon size
• Set view to icon view
• Hide toolbar, sidebar, etc.
• Set the background

[LinusU]

I'm going to start investigating SetFile now, since that would benefit the application at large, and report back here later.

[szwacz]

I don't know if .DS_Store is actually that scary, afterall you don't have to understand the whole spec of it, you don't want to parse it, you just want to put some values in predefined binnary :)

When I read about DMG images themselves it looks like more of a hedache http://newosxbook.com/DMG.html
Since this is fully proprietary standard it is only reverse-engineered to other platforms. There is something for linux: http://serverhorror.wordpress.com/2011/02/26/create-dmg-images-for-os-x-on-linux/ but I can find nothing for windows.

[LinusU]

Ohh, I actually thought that dmg images was just a raw binary file with a file system... I have some reading up to do :)

[LinusU]

The SetFile is a nightmare as well, but it seems like it's just really an extended attributes of 32 bytes (com.apple.FinderInfo).

This is the output on a clean folder with only the custom icon applied.

xattr -p com.apple.FinderInfo /tmp/test1607
00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This project might have some relevant info as well: https://code.google.com/p/profuse/wiki/XattrUtility

[LinusU]

Fun fun fun, I think I actually have a way to do SetFile cross-platform.

> x = require('xattr')
{ list: [Function], set: [Function] }
> x.list
[Function]
> x.list.toString()
'function () { [native code] }'
> x.list('/tmp/test1607')
{ 'com.apple.FinderInfo': '\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0004\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000' }
> x.list('/tmp/test1607')['com.apple.FinderInfo']
'\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0004\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000'
> var target = x.list('/tmp/test1607')['com.apple.FinderInfo']
undefined
> target
'\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0004\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000'
> x.set('/tmp/test1734', 'com.apple.FinderInfo', target)
true
> 

• /tmp/test1607 is a folder which I have used SetFile on
• /tmp/test1734 is a folder I made with mkdir

[LinusU]

Okay, so I don't know why this works (in that I don't know what the different bits mean) but this should create a buffer that can be written to the com.apple.FinderInfo xattr.

var buf = new Buffer(32);
buf.fill(0);
buf.writeUInt8(4, 8);
return buf.toString('binary');

[LinusU]

Seems like most of the things we need for .DS_Store is documented on the mozilla wiki.

Structure fwi0 type blob is Finder window information. Known length is 0x10 (16). The data is first four two-byte values representing the top, left, bottom, and right edges of the rect defining the content area of the window. The next four bytes represent the view of the window, "icnv" is icon view. The next four bytes are unknown.

Structure fwvh type shor is Finder window vertical height. If present, it overrides the height defined by the rect in fwi0. The Finder seems to create these (at least on 10.4) even though it will do the right thing for window height with only an fwi0 around, perhaps this is because the stored height is weird when accounting for toolbars and status bars.

Structure icvt type shor is icon view text label (filename) size.

Structure icvo type blob is icon view options. Known length 0x12 (18), first 4 bytes "icvo", then 8 unknown bytes (flags?), then 2 bytes corresponding to the selected icon view size, then 4 unknown bytes (0x6e 6f 6e 65) (the text "none", guess that this is the "keep arranged by" setting?)

Structure Iloc type blob is icon location for the last-identified file. Length is 0x10 (16), two 4-byte values representing the horizontal and vertical positions of the icon's center (not top-left). (Then, 6 bytes 0xff and 2 bytes 0?) For the purposes of the center, the icon only is taken into account, not any label. The icon's size comes from the icvo blob.

Structure BKGD type blob known length 0x0c (12) is for the background. It contains a reference to another strucutre, the first four bytes are PctB, followed by four bytes indicating the length of the referenced pict structure (same as the pict's length), then 00 00 00 13 (always the same?)

Structure pict type blob, length dependent on contents. This is for the background, along with BKGD. The contents: first, two empty bytes (00 00) followed by 4 bytes giving the length of the entire structure again, same as the length following "pictblob" in the header. Then, 4 bytes, 00 02 00 00. Then, 1 byte giving the length of the volume name. Then, 31 bytes to hold the volume name, unused bytes are 00...

This seems easy! 🍻

[LinusU]

I tried looking at the FinderInfo after running bless and most 00 where replaced by 20, no idea why thought 🎊

xattr -p com.apple.FinderInfo /tmp/test1734
20 20 20 20 20 20 20 20 04 20 20 20 20 20 20 20
20 20 20 20 00 00 00 00 20 20 20 20 20 20 20 20

GetFileInfo shows no difference with or without bless...

[LinusU]

I have now stopped using seticonflag so this should be one step closer to success!

[al45tair]

The FinderInfo data is documented (see the man page for getattrlist on a Mac OS X system), so there’s really no need to guess at its contents.

FWIW, I’ve already got portable Python code for reading/writing/editing .DS_Store files (see the ds_store module on PyPI), and semi-portable code for generating the Alias record you need to set background images (see mac_alias on PyPI). There are some issues with making the alias code fully portable (namely it needs to be able to extract HFS+ catalog node IDs from the filesystem somehow in order to generate the alias record correctly).

There’s also my dmgbuild tool, which is based on the above; that currently uses SetFile, though I have in mind that I might ditch that some time soon.

[LinusU]

Cool, I'm gonna have a look when I have time and updated my code.

Had a quick look at your documentation, it seems to be well done, keep up the good work! Feel free to contact me at any time if you need any help or want to discuss some file format :)