1. Mac Os Versions
2. Mac Os Standard Or Extended

Start quickly with the most recent versions of Word, Excel, PowerPoint, Outlook, OneNote and OneDrive —combining the familiarity of Office and the unique Mac features you love. Work online or offline, on your own or with others in real time—whatever works for what you’re doing. Windows and Mac Keyboard Differences. At least five keys have different names or symbols on a Windows keyboard than they do on a Mac keyboard, which can make it difficult to follow Mac-related instructions. For example, a software manual may tell you to hold down the command key ( ⌘ ), which appears to be missing from your Windows keyboard.

The Mac OS Extended Format (HFS+) is a volume format compatible with Mac OS 8.1 and higher, including Mac OS X. In terms of volume, folder, and file size limits, it is similar to the Macintosh Standard Format (HFS).
HFS+ or HFS Plus is a file system developed by Apple Computer Inc. to replace their Hierarchical File System (HFS) as the primary file system used in Macintosh computers (or other systems running Mac OS). It is also one of the formats used by the iPod music player. HFS+ is also referred to as Mac OS Extended Volume Hard Drive Format, where its predecessor, HFS, is also referred to as Mac OS Standard.
HFS+ is an improved version of HFS, supporting much larger files (block addresses are 32-bit length instead of 16-bit) and using Unicode (instead of Mac OS Roman or any of several other character sets) for naming the items (files, folders) - names which are also character encoded in UTF-16 and normalized to a form very nearly the same as Unicode Normalization Form D (NFD) (which means that precomposed characters like é are decomposed in the HFS+ filename and therefore count as two characters and UTF-16 implies that characters from outside the Basic Multilingual Plane - often seldom used and characters from ancient writing systems - also count as two characters in an HFS+ filename). HFS Plus permits filenames up to 255 UTF-16 characters in length, and n-forked files similar to NTFS, though until recently, almost no software takes advantage of forks other than the data fork and resource fork. HFS+ also uses a full 32-bit allocation mapping table, rather than HFS’s 16 bits. This was a serious limitation of HFS, meaning that no disk could support more than 65,536 allocation blocks under HFS. When disks were small, this was of little consequence, but as larger-capacity drives became available, it meant that the smallest amount of space that any file could occupy (a single allocation block) became excessively large, wasting significant amounts of space. For example, on a 1 GB disk, the allocation block size under HFS is 16 KB, so even a 1 byte file would take up 16 KB of disk space.

How do I know a hard disk is HFS+ format?

Select the hard disk in the Finder and choose the Get Info command in the File menu. The format information will specify either Mac OS Standard (hfs) or Mac OS Extended (hfs+).

What are the differences between HFS+ format and HFS format?

The most visible difference between HFS+ format and HFS format, other than the minimum file size, is the maximum number of files.

An HFS+ volume contains five special files:

1. Catalog file - Describes the folder and file hierarchy of the volume. It is organized as a 'balanced tree' for fast and efficient searches
2. Allocation file - Specifies whether an allocation block is free (similar to $Bitmap in NTFS). This is stored in a bitmap, specifying a free allocation block with a 'clear bit'
3. Attributes file - Contains attribute information regarding files or folders
4. Extents overflow file - Additional extents (contiguous allocation blocks allocated to forks) are stored in a b-tree in this file
5. Startup file - Allows computers to boot that do have built in support for HFS+ file systems

Related Glossary and Articles:

Manipulate disk images (attach, verify, burn, etc).

Disk images are containers that emulate disks. Like disks, they can be partitioned and formatted. Many uses of disk images blur the distinction between the disk image container and its content, but this distinction is critical to understanding disk images. The terms 'attach' and 'detach' are used to distinguish the way disk images are connected to and disconnected from the system.
For example, when you double-click a disk image in the macOS Finder, two separate things happen. First, the image is 'attached' to the system just like an external drive. Then, the kernel and Disk Arbitration probe the new device for recognized file structures. If any file structures are understood, the associated volumes will mount and appear in the
Finder.
Always consider whether a 'disk image' operation applies to the blocks of the disk image device or to the (often file-oriented) content of the image. For example, verify verifies that the blocks stored in a read- only disk image have not changed since it was created. On the other hand, create -srcfolder creates a disk image container, puts a filesystem
in it, and then copies the specified files to the new filesystem.

As of macOS 10.5, a more reliable, efficient, and scalable sparse format, UDSB (SPARSEBUNDLE), is recommended for persistent sparse images as long as a backing bundle (directory) is acceptable. macOS 10.5 also introduced
F_FULLFSYNC over AFP (on client and server), allowing proper journal flushes for HFS+J-bearing images. Critical data should never be stored in sparse disk images on file servers that don't support F_FULLFSYNC.
SPARSE (UDSP) images and shadow files were designed for intermediate use when creating other images (e.g. UDZO) when final image sizes are unknown. As of macOS 10.3.2, partially-updated SPARSE images are properly handled and are thus safe for persistent storage. SPARSE images are not recommended for persistent storage on versions of macOS earlier than 10.3.2 and should be avoided in favor of SPARSEBUNDLE images or UDRW
images and resize.
If more space is needed than is referenced by the hosted filesystem, hdiutil resize or diskutil(8) resize can help to grow or shrink the filesystem in an image. compact reclaims unused space in sparse images. Though they request that hosted HFS+ filesystems use a special 'front first' allocation policy, beware that sparse images can enhance the
effects of any fragmentation in the hosted filesystem.
To prevent errors when a filesystem inside of a sparse image has more free space than the volume holding the sparse image, HFS volumes inside sparse images will report an amount of free space slightly less than the amount of free space on the volume on which image resides. The image filesystem currently only behaves this way as a result of a direct attach action and will not behave this way if, for example, the filesystem is unmounted and remounted.

/dev Entry Access

Since any /dev entry can be treated as a raw disk image, it is worth noting which devices can be accessed when and how. /dev/rdisk nodes are character-special devices, but are 'raw' in the BSD sense and force block-aligned I/O. They are closer to the physical disk than the buffer cache. /dev/disk nodes, on the other hand, are buffered block-special
devices and are used primarily by the kernel's filesystem code.
It is not possible to read from a /dev/disk node while a filesystem is mounted from it, but anyone with read access to the appropriate /dev/rdisk node can use hdiutil verbs such as fsid or pmap with it. The DiskImages framework will attempt to use authopen(1) to open any device which it can't open (due to EACCES) for reading with open(2). This might cause apparent hangs while trying to access /dev entries while logged in remotely (an authorization panel is waiting on console).
Generally, the /dev/disk node is preferred for imaging devices (e.g. convert or create -srcdevice operations), while /dev/rdisk is usable for the quick pmap or fsid. In particular, converting the blocks of a mounted journaled filesystem to a read-only image will prevent the volume in the image from mounting (the journal will be permanently dirty).

Compatibility

macOS 10.0 supported the disk images of Disk Copy 6 on Mac OS 9. macOS 10.1 added sparse, encrypted, and zlib-compressed images. These images will not be recognized on macOS 10.0 (or will attach read/write, possibly allowing for their destruction). As the sparse, shadow, and encrypted formats have evolved, switches have been added to facilitate the creation of images that are compatible with older OS versions (at the expense of the performance and reliability improvements offered by the format enhancements). In particular, sparse images should not be expected to attach on versions of macOS older than that which created them.
With macOS 10.2, the most common image formats went 'in-kernel' (i.e. the DiskImages kernel extension served them without a helper process), image meta-data began being stored both as XML and in the embedded resource fork, and the default Disk Copy.app 'compressed' format became UDZO (breaking compatibility with 10.0). macOS 10.4 introduced bzip2 compression in the UDBZ format which provides smaller images (especially when combined with makehybrid) at the expense of backwards compatibility.
In macOS 10.4.7, the resource forks previously embedded in UDIF images were abandoned entirely to avoid metadata length limitations imposed by resource fork structures. As a result, UDIF images created on 10.4.7 and later will not, by default, be recognized by either macOS 10.1 or macOS 10.0. flatten can be used to customize the type of metadata stored in the image.
macOS 10.5 introduced sparse bundle images which compact quickly but are not recognized by previous OS versions. macOS 10.6 removed support for attaching SPARSEBUNDLE images from network file servers that don't support F_FULLFSYNC.
macOS 10.7 removed double-click support for images using legacy metadata; these can be rehabilitated using flatten and unflatten, or convert.

History

Disk images were first invented to electronically store and transmit representations of floppy disks for manufacturing replication. These images of floppies are typically referred to as 'Disk Copy 4.2' images, in reference to the application that created and restored them to floppy disks. Disk Copy 4.2 images were block-for-block representations of a floppy
disk, with no notion of compression. DART is a variant of the Disk Copy 4.2 format that supported compression.
NDIF (New Disk Image Format) images were developed to replace the Disk Copy 4.2 and DART image formats and to support images larger than a floppy disk. With NDIF and Disk Copy version 6, images could be'attached' as mass storage devices under Mac OS 9. Apple Data Compression (ADC) -- which carefully optimizes for fast decompression -- was
used to compress images that were typically created once and restored many times during manufacturing.
UDIF (Universal Disk Image Format) device images picked up where NDIF left off, allowing images to represent entire block devices and all the data therein: DDM, partition map, disk-based drivers, etc. For example, it can represent bootable CDs which can then be replicated from an image.
To ensure single-fork files (NDIF was dual-fork), it began embedding its resource fork in the data fork. UDIF is the native image format for OS X.
Raw disk images from other operating systems (e.g. .iso files) will be recognized as disk images and can be attached and mounted if macOS recognizes the filesystems. They can also be burned with hdiutil burn.

What's New

In macOS 10.12 Apple will provide an updated hdutil command able to work with the new file system.

macOS 10.7 added the ability to quickly render encrypted images inaccessible using the new erasekeys verb, which saves time versus securely overwriting the entire image.
In macOS 10.6, pmap was rewritten to use MediaKit's latest reporting routines so that it can properly support GPT partition maps. Also -debug now implies -verbose for all verbs.
macOS 10.5 changed the behavior of attach when run on an existing image or /dev node: if the image was attached but no volume was mounted, the volume would be mounted. Prior systems would return the /dev without mounting the volume. This change effectively removes the ability to create a second /dev node from an existing one.

Examples

Mount a Disk Image:
$ hdiutil attach /path/to/diskimage.dmg

Unmount a Disk Image:
$ hdiutil detach /dev/disk2s1

Create a Disk Image from a folders contents:
$ hdiutil create -volname 'Volume Name' -srcfolder /path/to/folder -ov diskimage.dmg

Create an encrypted Disk Image from a folders contents:
$ hdiutil create -encryption -stdinpass -volname 'Volume Name' -srcfolder /path/to/folder -ov encrypted.dmg

Mac Os Versions

The required password can be piped into the hdiutil command:
echo -n SEcurePa$$w0rd hdiutil...

Burn a Disk Image file (.iso, .img or .dmg) to a DVD:
$ hdiutil burn /path/to/image_file

“The beginning of wisdom is to call things by their right names” - Chinese Proverb

Related macOS commands:

asr - Apple Software Restore.
dd - Convert and copy a file, clone disks.
diskutil - Disk utilities - Format, Verify, Repair.
ditto - Copy files and folders.
authopen(1), hdid(8), ioreg(8), drutil(1), msdos.util(8), hfs.util(8), diskarbitrationd(8), /System/Library/CoreServices/DiskImageMounter.app.

Mac Os Standard Or Extended