Misplaced Pages

#776223

68-624: Compared to its predecessor HFS , also called Mac OS Standard or HFS Standard, HFS Plus supports 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 items. Like HFS, HFS Plus uses B-trees to store most volume metadata , but unlike most file systems that support hard links , HFS Plus supports hard links to directories. HFS Plus permits filenames up to 255 characters in length, and n-forked files similar to NTFS , though until 2005 almost no system software took advantage of forks other than

136-655: A Macintosh computer model behind: the original 128K Macintosh , which lacked sufficient memory to load the HFS code and was promptly discontinued. In 1998, Apple introduced HFS Plus to address inefficient allocation of disk space in HFS and to add other improvements. HFS Plus is still supported by current versions of Mac OS, but starting with Mac OS X , an HFS volume cannot be used for booting , and beginning with Mac OS X 10.6 (Snow Leopard), HFS volumes are read-only and cannot be created or updated. In macOS Sierra (10.12), Apple's release notes state that "The HFS Standard filesystem

204-411: A code unit starts a character can be determined without examining earlier code units (i.e. the type of code unit can be determined by the ranges of values in which it falls). UTF-8 shares these advantages, but many earlier multi-byte encoding schemes (such as Shift JIS and other Asian multi-byte encodings) did not allow unambiguous searching and could only be synchronized by re-parsing from the start of

272-597: 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 code units and UTF-16 implies that characters from outside the Basic Multilingual Plane also count as two code units in an HFS+ filename). HFS Plus permits filenames up to 255 UTF-16 code units in length. Formerly, HFS Plus volumes were embedded inside an HFS standard file system. This

340-503: A hint to perform byte-swapping for the remaining values. If the BOM is missing, RFC 2781 recommends that big-endian (BE) encoding be assumed. In practice, due to Windows using little-endian (LE) order by default, many applications assume little-endian encoding. It is also reliable to detect endianness by looking for null bytes, on the assumption that characters less than U+0100 are very common. If more even bytes (starting at 0) are null, then it

408-467: A larger 31-bit space and an encoding ( UCS-4 ) that would require 4 bytes per character. This was resisted by the Unicode Consortium , both because 4 bytes per character wasted a lot of memory and disk space, and because some manufacturers were already heavily invested in 2-byte-per-character technology. The UTF-16 encoding scheme was developed as a compromise and introduced with version 2.0 of

476-568: A mix of UTF-16, UTF-8, and legacy byte encodings. While there's been some UTF-8 support for even Windows XP, it was improved (in particular the ability to name a file using UTF-8) in Windows 10 insider build 17035 and the May 2019 update. As of May 2019, Microsoft recommends software use UTF-8 , on Windows and Xbox , instead of other 8-bit encodings. It is unclear if they are recommending usage of UTF-8 over UTF-16, though they do state "UTF-16 [..]

544-522: A mounted partition. An HFS+ partition with journaling enabled may be forcibly mounted with write access under Linux, but this is unsupported and unwise. A Google Summer of Code project to implement write support to journaled HFS+ was accepted by the Linux Foundation in 2011 but was not completed at that time and is still a work in progress. Progress and improvements to the HFS+ driver, including some updates to journaling support, are posted on

612-562: A number of techniques that are intended to avoid fragmentating files in HFS+. With Mac OS X 10.4, Apple added support for Inline Attribute Data records, something that had been a part of the Mac OS X implementation of HFS Plus since at least 10.0 , but always marked as "reserved for future use". Until the release of Mac OS X Server 10.4 , HFS Plus supported only the standard UNIX file system permissions ; however, 10.4 introduced support for access control list –based file security, which provides

680-423: A richer mechanism to define file permissions and is also designed to be fully compatible with the file permission models on other platforms such as Microsoft Windows XP and Windows Server 2003 . In Mac OS X Leopard 10.5, directory hard-linking was added as a fundamental part of Time Machine. In Mac OS X Snow Leopard 10.6, HFS+ compression was added using Deflate (Zlib). In open source and some other areas this

748-471: A smaller volume would take up much less space than if they resided on a large partition. The same problem existed in the FAT16 file system. HFS saves the case of a file that is created or renamed but is case-insensitive in operation. UTF-16 UTF-16 ( 16-bit Unicode Transformation Format) is a character encoding method capable of encoding all 1,112,064 valid code points of Unicode. The encoding

SECTION 10

#1732787549777

816-638: A system with a few hundred kilobytes of storage and perhaps a hundred files, but as the systems grew into megabytes and thousands of files, the performance degraded rapidly. The solution was to replace MFS's directory structure with one more suitable to larger file systems. HFS replaced the flat table structure with the Catalog File which uses a B-tree structure that could be searched very quickly regardless of size. HFS also redesigned various structures to be able to hold larger numbers, 16-bit integers being replaced by 32-bit almost universally. Oddly, one of

884-469: A time, meaning that many programs may be waiting in queue due to one program "hogging" the system. It is also a serious reliability concern, as damage to this file can destroy the entire file system. This contrasts with other file systems that store file and directory records in separate structures (such as DOS's FAT file system or the Unix File System ), where having structure distributed across

952-467: A typical HFS Plus volume: HFS Plus lacks several features considered staples of modern file systems like ZFS and NTFS . Data checksums are the most routinely cited missing feature. Besides checksumming, features of modern file systems that HFS+ lacks include: HFS Plus was not designed for Unix-like systems, so features such as file system permissions and hard links had to be retrofitted when Apple moved to Mac OS X. The Linux kernel includes

1020-414: Is variable-length as code points are encoded with one or two 16-bit code units . UTF-16 arose from an earlier obsolete fixed-width 16-bit encoding now known as UCS-2 (for 2-byte Universal Character Set), once it became clear that more than 2 (65,536) code points were needed, including most emoji and important CJK characters such as for personal and place names. UTF-16 is used by systems such as

1088-623: Is "constructed from a pair of Unicode scalar values" (and those values are outside the BMP and require 4 bytes each). UTF-16 in no way assists in "counting characters" or in "measuring the width of a string". UTF-16 is often claimed to be more space-efficient than UTF-8 for East Asian languages, since it uses two bytes for characters that take 3 bytes in UTF-8. Since real text contains many spaces, numbers, punctuation, markup (for e.g. web pages), and control characters, which take only one byte in UTF-8, this

1156-495: Is 16 KB, so even a 1 byte file would take up 16 KB of disk space. This situation was less of a problem for users having large files (such as pictures, databases or audio) because these larger files wasted less space as a percentage of their file size. Users with many small files, on the other hand, could lose a copious amount of space due to large allocation block size. This made partitioning disks into smaller logical volumes very appealing for Mac users, because small documents stored on

1224-509: Is HFSExplorer written by Erik Larsson. HFSExplorer is a Java application for viewing and extracting files from an HFS+ volume (Mac OS Extended) or an HFSX volume (Mac OS Extended, Case-sensitive). The volume can be located either on a physical disk, in various Apple disk image and sparse disk image formats , or a raw file system dump. However, HFSExplorer is a read-only solution; it cannot write to HFS-formatted volumes. Hierarchical File System (Apple) Hierarchical File System ( HFS )

1292-775: Is a proprietary file system developed by Apple Inc. for use in computer systems running Mac OS . Originally designed for use on floppy and hard disks , it can also be found on read-only media such as CD-ROMs . HFS is also referred to as Mac OS Standard (or HFS Standard ), while its successor, HFS Plus , is also called Mac OS Extended (or HFS Extended). With the introduction of Mac OS X 10.6 , Apple dropped support for formatting or writing HFS disks and images , which remained supported as read-only volumes until macOS 10.15 . Starting with macOS 10.15, HFS disks can no longer be read. Apple introduced HFS in September 1985, specifically to support Apple's first hard disk drive for

1360-733: Is a unique burden that Windows places on code that targets multiple platforms." The IBM i operating system designates CCSID ( code page ) 13488 for UCS-2 encoding and CCSID 1200 for UTF-16 encoding, though the system treats them both as UTF-16. UTF-16 is used by the Qualcomm BREW operating systems; the .NET environments; and the Qt cross-platform graphical widget toolkit . Symbian OS used in Nokia S60 handsets and Sony Ericsson UIQ handsets uses UCS-2. iPhone handsets use UTF-16 for Short Message Service instead of UCS-2 described in

1428-466: Is also available for mounting HFS and HFS+ drives, optical discs, and other media in Windows Explorer, and allows both reading and writing to the volume, as well as repairing and formatting Mac disks. A commercial product, Paragon's HFS+ for Windows allows full read and write and disk management from all versions of Windows from Windows XP to Windows Server 2008. A free ( GPL ) alternative

SECTION 20

#1732787549777

1496-484: Is big-endian. The standard also allows the byte order to be stated explicitly by specifying UTF-16BE or UTF-16LE as the encoding type. When the byte order is specified explicitly this way, a BOM is specifically not supposed to be prepended to the text, and a U+FEFF at the beginning should be handled as a ZWNBSP character. Most applications ignore a BOM in all cases despite this rule. For Internet protocols, IANA has approved "UTF-16", "UTF-16BE", and "UTF-16LE" as

1564-444: Is declared by under 0.003% of public web pages. UTF-8 , by comparison, accounts for over 98% of all web pages. The Web Hypertext Application Technology Working Group (WHATWG) considers UTF-8 "the mandatory encoding for all [text]" and that for security reasons browser applications should not use UTF-16. The variable length character of UTF-16, combined with the fact that most characters are not variable length (so variable length

1632-694: Is encoded either as one or two 16-bit code units . Code points less than 2 ("in the BMP") are encoded with a single 16-bit code unit equal to the numerical value of the code point, as in the older UCS-2. Code points greater than or equal to 2 ("above the BMP") are encoded using two 16-bit code units. These two 16-bit code units are chosen from the UTF-16 surrogate range 0xD800–0xDFFF which had not previously been assigned to characters. Values in this range are not used as characters, and UTF-16 provides no legal way to code them as individual code points. A UTF-16 stream, therefore, consists of single 16-bit codes outside

1700-512: Is in progress to lift this restriction. Under Linux's current HFS+ driver, journaling must be disabled in order to write data safely onto an HFS+ partition. Provided the partition isn't being used by Apple's Time Machine software, journaling can be disabled under macOS: Using Disk Utility in OS X Yosemite, the user may hold Alt/Option and click "Disable Journaling" on the File menu, having first selected

1768-405: Is no longer supported." However, read-only HFS Standard support continued to work until the release of macOS 10.15 , ending official support for classic HFS Standard after 35 years. A storage volume is inherently divided into logical blocks of 512 bytes. The Hierarchical File System groups these logical blocks into allocation blocks , which can contain one or more logical blocks, depending on

1836-563: Is only true for artificially constructed dense blocks of text. A more serious claim can be made for Devanagari and Bengali , which use multi-letter words and all the letters take 3 bytes in UTF-8 and only 2 in UTF-16. In addition the Chinese Unicode encoding standard GB 18030 always produces files the same size or smaller than UTF-16 for all languages, not just for Chinese (it does this by sacrificing self-synchronization). UTF-16

1904-410: Is rarely tested), has led to many bugs in software, including in Windows itself, the solution is usually adopting UTF-8 , as most software has done including (partially) Windows itself and Java and JavaScript. In the late 1980s, work began on developing a uniform encoding for a "Universal Character Set" ( UCS ) that would replace earlier language-specific encodings with one coordinated system. The goal

1972-425: Is referred to as AppleFSCompression or decmpfs. Compressed data may be stored in either an extended attribute or the resource fork. When using non-Apple APIs, AppleFSCompression is not always completely transparent. OS X 10.9 introduced two new algorithms: LZVN (libFastCompression), and LZFSE . In Mac OS X Lion 10.7, logical volume encryption (known as FileVault 2 ) was added to the operating system. This addition to

2040-415: Is still used. JavaScript may use UCS-2 or UTF-16. As of ES2015, string methods and regular expression flags have been added to the language that permit handling strings from an encoding-agnostic perspective. UEFI uses UTF-16 to encode strings by default. Swift , Apple's preferred application language, used UTF-16 to store strings until version 5 which switched to UTF-8. Quite a few languages make

2108-478: Is used for text in the OS ; API of all currently supported versions of Microsoft Windows (and including at least all since Windows CE / 2000 / XP / 2003 / Vista / 7 ) including Windows 10 . In Windows XP, no code point above U+FFFF is included in any font delivered with Windows for European languages. Older Windows NT systems (prior to Windows 2000) only support UCS-2 . Files and network data tend to be

HFS Plus - Misplaced Pages Continue

2176-457: The 3GPP TS 23.038 ( GSM ) and IS-637 ( CDMA ) standards. The Joliet file system , used in CD-ROM media, encodes file names using UCS-2BE (up to sixty-four Unicode characters per file name). Python version 2.0 officially only used UCS-2 internally, but the UTF-8 decoder to "Unicode" produced correct UTF-16. There was also the ability to compile Python so that it used UTF-32 internally, this

2244-805: The Boot Camp software in Mac OS X 10.6 . This means users on these systems can read data on the HFS+ drive, but not write to them. Microsoft has created an HFS+ driver for the Xbox 360 mainly for the purpose of reading HFS+-formatted iPods. A free and opensource software – jHFSplus, based on HFSExplorer and jpfm – can be used to mount hfs/hfs+ partitions as read-only virtual folders. A freeware plugin for Total Commander exists, that can read, among others, HFS and HFS+ filesystems. DiskInternals Linux Reader can be used to extract/save folders/files out of HFS and HFS+ Hard Drives/Partitions. A commercial product, MacDrive,

2312-673: The HFS Wrapper that is typical of HFS Plus volumes and they optionally support case sensitivity for file and folder names. HFSX volumes can be recognized by two entries in the Volume Header, a value of HX in the signature field and 5 in the version field. Mac OS X 10.3 also marked Apple's adoption of Unicode 3.2 decomposition, superseding the Unicode 2.1 decomposition used previously. This change caused problems for developers writing software for Mac OS X. Mac OS X 10.3 introduced

2380-522: The Microsoft Windows API , the Java programming language and JavaScript /ECMAScript. It is also sometimes used for plain text and word-processing data files on Microsoft Windows. It is used by more modern implementations of SMS . UTF-16 is the only encoding (still) allowed on the web that is incompatible with 8-bit ASCII . However it has never gained popularity on the web, where it

2448-409: The Unicode Consortium , the latter representing mostly manufacturers of computing equipment. The two groups attempted to synchronize their character assignments so that the developing encodings would be mutually compatible. The early 2-byte encoding was originally called "Unicode", but is now called "UCS-2". When it became increasingly clear that 2 characters would not suffice, IEEE introduced

2516-527: The data fork and resource fork . HFS Plus also uses a full 32-bit allocation mapping table rather than HFS's 16 bits, improving the use of space on large disks. Codenamed Sequoia in development, HFS+ was introduced with the January 19, 1998, release of Mac OS 8.1 . With the release of the Mac OS X 10.2.2 update on November 11, 2002, Apple added optional journaling features to HFS Plus for improved data reliability. These features were accessible through

2584-401: The high surrogates ( 0xD800–0xDBFF ), low surrogates ( 0xDC00–0xDFFF ), and valid BMP characters (0x0000–0xD7FF, 0xE000–0xFFFF) are disjoint , it is not possible for a surrogate to match a BMP character, or for two adjacent code units to look like a legal surrogate pair . This simplifies searches a great deal. It also means that UTF-16 is self-synchronizing on 16-bit words: whether

2652-593: The GUI, using the Disk Utility application in Mac OS X Server, but only accessible through the command line in the standard desktop client. With Mac OS X v10.3, all HFS Plus volumes on all Macs were set to be journaled by default. Within the system, an HFS Plus volume with a journal is identified as HFSJ . Mac OS X 10.3 also introduced another version of HFS Plus called HFSX . HFSX volumes are almost identical to HFS Plus volumes, except that they are never surrounded by

2720-541: The Macintosh in September 1985, where it was loaded into RAM from a MFS floppy disk on boot using a patch file ("Hard Disk 20"). However, HFS was not widely introduced until it was included in the 128K ROM that debuted with the Macintosh Plus in January 1986 along with the larger 800 KB floppy disk drive for the Macintosh that also used HFS. The introduction of HFS was the first advancement by Apple to leave

2788-531: The Macintosh, replacing the Macintosh File System (MFS), the original file system which had been introduced over a year and a half earlier with the first Macintosh computer. HFS drew heavily upon Apple's first operating system with a hierarchical file system , SOS for the failed Apple III , which also served as the basis for hierarchical file systems on the Apple IIe and Apple Lisa . HFS

HFS Plus - Misplaced Pages Continue

2856-656: The Unicode standard in July 1996. It is fully specified in RFC 2781, published in 2000 by the IETF . UTF-16 is specified in the latest versions of both the international standard ISO/IEC 10646 and the Unicode Standard. "UCS-2 should now be considered obsolete. It no longer refers to an encoding form in either 10646 or the Unicode Standard." UTF-16 will never be extended to support a larger number of code points or to support

2924-405: The allocation block size. When disks were small, this was of little consequence, because the individual allocation block size was trivial, but as disks started to approach the 1 GB mark, the smallest amount of space that any file could occupy (a single allocation block) became excessively large, wasting significant amounts of disk space. For example, on a 1 GB disk, the allocation block size under HFS

2992-479: The byte order of code units, UTF-16 allows a byte order mark (BOM), a code point with the value U+FEFF, to precede the first actual coded value. (U+FEFF is the invisible zero-width non-breaking space /ZWNBSP character). If the endian architecture of the decoder matches that of the encoder, the decoder detects the 0xFEFF value, but an opposite-endian decoder interprets the BOM as the noncharacter value U+FFFE reserved for this purpose. This incorrect result provides

3060-426: The code point are distributed among the UTF-16 bytes. Additional bits added by the UTF-16 encoding process are shown in black. UTF-16 and UCS-2 produce a sequence of 16-bit code units. Since most communication and storage protocols are defined for bytes, and each unit thus takes two 8-bit bytes, the order of the bytes may depend on the endianness (byte order) of the computer architecture. To assist in recognizing

3128-475: The code points that were replaced by surrogates, as this would violate the Unicode Stability Policy with respect to general category or surrogate code points. (Any scheme that remains a self-synchronizing code would require allocating at least one Basic Multilingual Plane (BMP) code point to start a sequence. Changing the purpose of a code point is disallowed.) Each Unicode code point

3196-466: The disk means that damaging a single directory is generally non-fatal and the data may possibly be re-constructed with data held in the non-damaged portions. Additionally, the limit of 65,535 allocation blocks resulted in files having a "minimum" size equivalent 1/65,535th the size of the disk. Thus, any given volume, no matter its size, could only store a maximum of 65,535 files. Moreover, any file would be allocated more space than it actually needed, up to

3264-551: The encoding part of the string object, and thus store and support a large set of encodings including UTF-16. Most consider UTF-16 and UCS-2 to be different encodings. Examples are the PHP language and MySQL . A method to determine what encoding a system is using internally is to ask for the "length" of string containing a single non-BMP character. If the length is 2 then UTF-16 is being used. 4 indicates UTF-8. 3 or 6 may indicate CESU-8 . 1 may indicate UTF-32, but more likely indicates

3332-415: The few places this "upsizing" did not take place was the file directory itself, which limits HFS to a total of 65,535 files on each logical disk. While HFS is a proprietary file system format, it is well-documented; there are usually solutions available to access HFS-formatted disks from most modern operating systems . Apple introduced HFS out of necessity with its first 20 MB hard disk offering for

3400-428: The hfsplus module for mounting HFS+ filesystems read-write. HFS+ fsck and mkfs have been ported to Linux and are part of the hfsprogs package. In 2009, these drivers were diagnosed to be corrupting HFS+ drives with a capacity greater than 2 TB. Consequently, Linux distributions such as Debian and Ubuntu stopped allowing mounting of HFS+ drives or partitions greater than 2 TB. As of February 2011, work

3468-414: The linux-fsdevel mailing list from time to time. As of July 2011, Paragon Software Group provided kernel drivers that allow full read-write access to HFS+ journaled volumes. The product is a proprietary implementation of HFS+ based on Paragon's proprietary UFSD library. There are both free and paid editions of the driver, and they include a utility for checking and repairing HFS+ volumes. According to

SECTION 50

#1732787549777

3536-490: The names for these encodings (the names are case insensitive). The aliases UTF_16 or UTF16 may be meaningful in some programming languages or software applications, but they are not standard names in Internet protocols. Similar designations, UCS-2BE and UCS-2LE , are used to show versions of UCS-2 . A "character" may use any number of Unicode code points. For instance an emoji flag character takes 8 bytes, since it

3604-414: The number of allocation blocks depends on the total size of the volume. HFS Plus uses a larger value to address allocation blocks than HFS, 32 bits rather than 16 bits; this means it can access 4,294,967,296 (= 2) allocation blocks rather than the 65,536 (= 2) allocation blocks available to HFS. When disks were small, this was of little consequence, but as larger-capacity drives became available, it meant that

3672-440: The online documentation (free version or the paid edition), both the free edition and the paid edition currently support Linux kernels from 2.6.36 up to 4.12.x. Ubuntu , Debian , Fedora Linux , Rocky Linux , Red Hat Enterprise Linux , OpenSUSE and CentOS are the only Linux distributions officially supported. As of May 2012, Apple has only released read-only HFS+ drivers for Windows XP, Windows Vista, and Windows 7 as part of

3740-566: The operating system in no way changed the logical structure of the file system. Apple's logical volume manager is known as Core Storage and its encryption at the volume level can apply to file systems other than HFS Plus. With appropriate hardware, both encryption and decryption should be transparent. HFS Plus volumes are divided into sectors (called logical blocks in HFS), that are usually 512 bytes in size. These sectors are then grouped together into allocation blocks which can contain one or more sectors;

3808-402: The other planes are encoded as two 16-bit code units called a surrogate pair . The first code unit is a high surrogate and the second is a low surrogate (These are also known as "leading" and "trailing" surrogates, respectively, analogous to the leading and trailing bytes of UTF-8. ): Illustrated visually, the distribution of U' between W1 and W2 looks like: Since the ranges for

3876-500: 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. HFS Plus's system greatly improves space utilization on larger disks as a result. File and folder names in HFS Plus are also encoded in UTF-16 and normalized to

3944-629: The standard states that such arrangements should be treated as encoding errors. It is possible to unambiguously encode an unpaired surrogate (a high surrogate code point not followed by a low one, or a low one not preceded by a high one) in the format of UTF-16 by using a code unit equal to the code point. The result is not valid UTF-16, but the majority of UTF-16 encoder and decoder implementations do this when translating between encodings. To encode U+10437 (𐐷) to UTF-16: To decode U+10437 (𐐷) from UTF-16: The following table summarizes this conversion, as well as others. The colors indicate how bits from

4012-478: The string. UTF-16 is not self-synchronizing if one byte is lost or if traversal starts at a random byte. Because the most commonly used characters are all in the BMP, handling of surrogate pairs is often not thoroughly tested. This leads to persistent bugs and potential security holes, even in popular and well-reviewed application software (e.g. CVE - 2008-2938 , CVE- 2012-2135 ). The official Unicode standard says that no UTF forms, including UTF-16, can encode

4080-446: The surrogate code points. Since these will never be assigned a character, there should be no reason to encode them. However, Windows allows unpaired surrogates in filenames and other places, which generally means they have to be supported by software in spite of their exclusion from the Unicode standard. UCS-2, UTF-8, and UTF-32 can encode these code points in trivial and obvious ways, and a large amount of software does so, even though

4148-613: The surrogate range, and pairs of 16-bit values that are within the surrogate range. Both UTF-16 and UCS-2 encode code points in this range as single 16-bit code units that are numerically equal to the corresponding code points. These code points in the Basic Multilingual Plane (BMP) are the only code points that can be represented in UCS-2. As of Unicode 9.0, some modern non-Latin Asian, Middle-Eastern, and African scripts fall outside this range, as do most emoji characters. Code points from

SECTION 60

#1732787549777

4216-401: The total size of the volume. HFS uses a 16-bit value to address allocation blocks, limiting the number of allocation blocks to 65,535 (2 -1). Five structures make up an HFS volume: The Catalog File, which stores all the file and directory records in a single data structure, results in performance problems when the system allows multitasking , as only one program can write to this structure at

4284-436: The volume requires a system with HFS Plus support. The original HFS volume contains a signature and an offset to the embedded HFS Plus volume within its volume header. All allocation blocks in the HFS volume which contain the embedded volume are mapped out of the HFS allocation file as bad blocks . Notable among file systems used for Unix systems, HFS Plus does not support sparse files . There are nine structures that make up

4352-601: Was developed by Patrick Dirks and Bill Bruffey. It shared a number of design features with MFS that were not available in other file systems of the time (such as DOS 's FAT ). Files could have multiple forks (normally a data and a resource fork ), which allowed the main data of the file to be stored separately from resources such as icons that might need to be localized. Files were referenced with unique file IDs rather than file names, and file names could be up to 31 characters long. However, MFS had been optimized to be used on very small and slow media, namely floppy disks , so HFS

4420-413: Was introduced to overcome some of the performance problems that arrived with the introduction of larger media, notably hard drives . The main concern was the time needed to display the contents of a folder. Under MFS all of the file and directory listing information was stored in a single file, which the system had to search to build a list of the files stored in a particular folder. This worked well with

4488-555: Was phased out by the Tiger transition to Intel Macs, where the HFS Plus file system was not embedded inside a wrapper. The wrapper had been designed for two purposes; it allowed Macintosh computers without HFS Plus support in their ROM to boot HFS Plus volumes and it also was designed to help users transition to HFS Plus by including a minimal HFS volume with a read-only file called Where_have_all_my_files_gone? , explaining to users with versions of Mac OS 8.0 and earlier without HFS Plus, that

4556-536: Was sometimes done on Unix. Python 3.3 switched internal storage to use one of ISO-8859-1 , UCS-2, or UTF-32 depending on the largest code point in the string. Python 3.12 drops some functionality (for CPython extensions) to make it easier to migrate to UTF-8 for all strings. Java originally used UCS-2, and added UTF-16 supplementary character support in J2SE 5.0 . Recently they have encouraged dumping support for any 8-bit encoding other than UTF-8 but internally UTF-16

4624-426: Was to include all required characters from most of the world's languages, as well as symbols from technical domains such as science, mathematics, and music. The original idea was to replace the typical 256-character encodings, which required 1 byte per character, with an encoding using 65,536 (2 ) values, which would require 2 bytes (16 bits) per character. Two groups worked on this in parallel, ISO/IEC JTC 1/SC 2 and

#776223