Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
DMG created with APFS in macOS 10.13 #159
It is not a bug... when creating .dmg images,
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
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...
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
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
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.