DMG created with APFS in macOS 10.13

[aonez]

As commented here #153 (comment) by @ScarabMonkey.

• Force HFS+/HFSX instead in 1.0.15 version -> ForceHFSDMG
• Add an option in 1.2 version to use APFS when supported

[MaxPower85]

It is not a bug... when creating .dmg images, hdiutil chooses the filesystem based on which filesystem the source volume is using... so if the source volume is APFS, then it uses APFS... if the source volume was HFS+, it would use HFS+... if it was HFSX (case sensitive HFS+), it would use HFSX... and if the source volume was ExFat, it would use ExFat.

Forcing a different filesystem should not be done unless the user is sure that there aren't any files that could cause issues, so it wouldn't result in data loss if he forces the use of a filesystem that doesn't support copying all those files to it as they are.

Don't forget that some users could be using HFSX on some partition (or in some other DMG) and that they may need support for it.

The usual HFS+ that's used by default on Macs is not case sensitive.

On a case sensitive filesystem, filenames like file.jpg, File.jpg and FILE.jpg are considered different filenames, so there could be different files with filenames that only differ by one or more letters being uppercase/lowercase in the same directory... but you can't have that on a case insensitive filesystem because on a case insensitive filesystem filenames like file.jpg, File.jpg and FILE.jpg would be considered the same.

Because of that, you should not force hdiutil to use the case insensitive HFS+ when creating new .dmg images, so it wouldn't leave out some files from that .dmg if the source volume was case sensitive.

If some users want to use a folder on an APFS volume to create a HFS+ .dmg image, you could just add an option for them to choose HFS+, but include the HFSX among the options too.

And you could also add a drop down menus for the user to change the compression format if he wants... -format UDZO option is for zlib compression, -format UDBZ is for bzip2 compression and -format ULFO is for lzfse compression.

When zlib compression is used, you can also add an option to select the compression level... documentation for hdiutil says that you can specify the compression level with -imagekey zlib-level=value when zlib compression is used and that if you don't specify the compression level that it defaults to level 1 (fastest)... maybe show that slider to select the compression level when zlib compression is selected or just in the drop-down menu for selecting the compression format add "zlib (level 9)" besides the "zlib (fast)" option if someone wants to use higher compression.

Also, don't forget to mention somewhere something like "For better backwards compatibility, use HFS+ with zlib compression", just in case if some less-techie users aren't sure what they should choose if they want compatibility with older versions of OS X... and if the source volume is case sensitive and they select HFS+, use HFSX instead, just in case.

I'm not sure should other options be added... I guess -format ROCo (compressed NDIF image) with an .img file extension (hdiutil adds that extension automatically if it's omitted when you choose that format) would be good to have if someone needs compatibility with Classic Mac OS 9, but those are not mountable on recent versions of macOS... I tried creating an image with the even older DC42 format too (if someone needed compatibility with System 6), but that didn't seem to work on Sierra even with an empty folder for some reason (the documentation does say that it's an obsolete format... but the option is still there).

[MaxPower85]

Also... if HSFX was forced... although that should avoid issues of some files being left out if the source folder was on a case sensitive filesystem... and well written apps should work just as well from a case sensitive volume as they work on a case insensitive volume... there could theoretically be issues like if some app's developers coded some app to refer to some file as "somefile" or "SOMEFILE" (or maybe even both if different programers worked on different parts of the app), but the actual filename was something like "SomeFile"... or maybe they wanted some really simple way to check is some file a JPEG image and they just check does the filename end in ".jpg", but don't check for ".JPG"... developers should fix issues like those, but maybe some developers just don't see it as their priority to fix issues that affect their app when users aren't using the default filesystem.

[aonez]

@ScarabMonkey released version 1.0.15 does not use APFS. You can force it though.
@MaxPower85 Keka is detecting the sources to determine if they come from a APFS case in/sensitive, then uses HFS+/HFSX. Thanks for all the info, as always!

I'll try to add GUI options to customize this on 1.2.0.

[aonez]

Sadly this is not working in a sandbox environment. Current versions 1.1.x and future 1.2.x only create HFS+ images. No APFS and no HFSX.