Jump to content

EA DATA. SF

From Alfawiki
Adapted from the English Wikipedia article EA DATA. SF, available under CC BY-SA 4.0Updated 9 August 2025
File Allocation Table (FAT)
Company typeFile system
IndustryComputer software / Data storage
Founded1977
FounderMarc McDonald
ProductsFAT12, FAT16, FAT32, exFAT

File Allocation Table (FAT) is a file system initially developed for personal computers and served as the standard file system for MS-DOS and Windows 9x. First introduced in 1977 for use with floppy disks, it was subsequently modified to support hard disks and other storage media. As disk storage capacities expanded, several versions emerged, including FAT12, FAT16, FAT32, and exFAT. Starting with Windows XP, FAT was succeeded by NTFS as the default file system. Nevertheless, FAT continues to be prevalent on low-capacity solid-state storage devices such as SD card, MultiMediaCard (MMC), and eMMC, owing to its widespread compatibility and straightforward design.

Historical

During the era of DOS and Windows 9x, FAT was the dominant file system for hard disks. Although Microsoft launched NTFS with Windows NT in 1993, FAT remained the preferred choice for consumer systems until the release of Windows XP in 2001. The final Windows version to default to FAT was Windows Me.

For floppy disks, FAT has been formalized under ECMA-107 and ISO/IEC 9293:1994 standards, encompassing FAT12 and FAT16 with only short 8.3 filename conventions; support for long filenames through VFAT involved partial patent restrictions. FAT12 is primarily employed on floppy disks, while FAT16 and FAT32 are typically used on larger storage devices.

Modern

Within EFI-compliant machines, FAT is utilized internally for the EFI system partition.

It remains a common choice for drives accessed by multiple operating systems such as Windows and Linux. Windows offers a utility that converts FAT to NTFS without data loss, although reversing this process is complex. FAT supports various removable media including floppy disks, super-floppies, memory cards, flash memory cards, and USB flash drives. Additionally, it is compatible with portable electronics like PDAs, digital cameras, camcorders, media players, and mobile phones.

Since 1998, the majority of digital cameras have adopted the DCF standard, which requires physical storage formatted with FAT12, FAT16, FAT32, or exFAT using logical 8.3 filenames to maintain interoperability.

Technical details

The file system maintains an index structure called the File Allocation Table (FAT) stored on the device to monitor data chains associated with files. This table is allocated statically during formatting and functions as a linked list where each entry corresponds to a cluster, a continuous block of disk space. Every entry either references the subsequent cluster in a file’s sequence or indicates end-of-file, free space, or reserved sectors. The root directory holds the initial cluster number for each file; from there, the operating system follows the chain through the FAT to access all clusters belonging to that file. Subdirectories are treated as special files containing directory entries.

Each entry in the FAT has a fixed size of 12, 16, or 32 bits. The maximum size of files or volumes depends on the highest representable value (excluding reserved codes) multiplied by cluster size. Since even very small files require allocation of at least one entire cluster, this can result in inefficient use of disk space when numerous small files are stored.

Originally designed as an 8-bit addressing scheme, FAT extended its cluster address width as storage sizes increased—leading to three principal versions named according to their entry bit lengths: 12 (FAT12), 16 (FAT16), and 32 (FAT32).

Variants

The FAT file system has multiple variations, such as FAT12, FAT16, and FAT32. The term FAT16 applies both to the original FAT systems with 16-bit cluster entries and to subsequent iterations. The "VFAT" extension, which is optional, allows for long filenames and is compatible across all FAT types. Volumes utilizing VFAT long filenames can still be accessed by operating systems lacking VFAT support.

Initial 8-bit FAT

The first iteration of the FAT file system, originally named the FAT structure, was created by Marc McDonald after consultations with Bill Gates. It employed 8-bit table entries with cluster numbers valid up to 0xBF. This system was introduced in Microsoft's Standalone Disk BASIC-80 for an Intel 8080-based successor to the NCR 7200 model VI data-entry terminal, which used 8-inch floppy disks around 1977 or 1978.

In 1978, Standalone Disk BASIC-80 was adapted for the Intel 8086 using an emulator running on a DEC PDP-10 because actual 8086 hardware was not yet available. Microsoft's MIDAS OS for 8080/Z80 platforms, developed by McDonald from 1979 onward, also incorporated the FAT system. While Standalone Disk BASIC maintained three copies of the FAT, MIDAS allowed this number to be set as a parameter and was designed to support 10-, 12-, and 16-bit FAT variants. Directory entries were sized at 16 bytes in Standalone Disk BASIC and expanded to 32 bytes in MIDAS.

In May 1979, Tim Paterson of Seattle Computer Products became acquainted with Microsoft's FAT structure while assisting with the port of the Standalone Disk BASIC-86 emulator to SCP’s S-100 bus 8086 CPU board. This product was demonstrated at Lifeboat Associates' exhibit during the National Computer Conference in June 1979, where Paterson learned about the advanced FAT implementation in MDOS/MIDAS and engaged in design discussions with McDonald.

FAT12

From April to August 1980, Tim Paterson enhanced the FAT design by expanding it to 12 bits for SCP's 8086 operating system, QDOS 0.10. He reduced the number of FAT copies to two and repositioned the root directory between the FAT area and data region, defining FAT12. The filename length was increased to accommodate CP/M-style 8.3 filenames. By August, QDOS was renamed 86-DOS, which in version 0.42 changed directory entry sizes from 16 to 32 bytes to incorporate file date stamps and extend file size limits beyond 16 MB. The release of 86-DOS 1.00 occurred in early 1981, eventually evolving into Microsoft's MS-DOS and IBM's PC DOS later that year.

FAT12 utilized 12-bit cluster address entries, restricting clusters to a maximum of 4,068 due to reserved values indicating end-of-chain or bad sectors. To conserve disk space, two 12-bit FAT entries were packed into three bytes, making it suitable for floppy disks and small hard drives up to 32 MB in size. The DOS 3.31 FAT16B variant expanded volume capacity by supporting sector numbers represented with 32 bits.

Control structures were contained within the first track to minimize read/write head movement; any bad sectors within this area rendered disks unusable, leading formatting utilities to reject such disks. Bad sectors were permitted only within data regions and marked unusable using the reserved FAT value 0xFF7.

86-DOS supported various floppy disk formats on 8-inch drives, whereas IBM PC DOS 1.0 (1981) supported a single-sided 5.25-inch floppy disk at a capacity of 160 KB (FAT ID 0xFE). PC DOS 1.1 introduced double-sided disks with a capacity of 320 KB (FAT ID 0xFF), and PC DOS 2.0 added support for formats featuring nine sectors per track with sizes of 180 KB and 360 KB (FAT IDs 0xFC and 0xFD). Early DOS versions recorded only file modification dates; PC DOS 1.1 added modification time tracking as well. Initially, file attributes included hidden and system flags; subdirectory support was not available at that time.

The IBM PC XT was the first personal computer equipped with a hard drive; PC DOS 2.0 provided support for it using FAT12 (FAT ID 0xF8). Fixed cluster sizes imposed a maximum partition size of 16 MB on hard disks with sector sizes of 512 bytes.

The introduction of the BIOS Parameter Block (BPB) came with PC DOS 2.0, adding read-only, archive, volume label, and directory attributes that enabled hierarchical subdirectory structures.

MS-DOS version 3.0 added compatibility for high-density (1.2 MB) 5.25-inch floppy disks (media descriptor 0xF9) by increasing sectors per track to accommodate larger FAT tables.

Today, FAT12 remains the standard file system format for all common floppy disk types, including both the traditional 1.44 MB and later extended-capacity 2.88 MB disks (media descriptor 0xF0).

Early FAT16 Implementation

In 1984, IBM launched the PC AT, which required PC DOS 3.0 to operate its 20 MB hard drive. At the same time, Microsoft released MS-DOS 3.0. This version expanded cluster addresses to 16 bits, permitting up to 65,526 clusters per volume; however, the maximum partition size remained capped at 32 MB. This initial 16-bit cluster format differs from the widely recognized FAT16 standard used today.

A partition type 0x04 identifies this FAT16 variant, which supports fewer than 65,536 sectors (equivalent to partitions smaller than 32 MB when using 512-byte sectors). By employing smaller clusters, FAT16 enhanced disk space utilization, particularly benefiting storage efficiency for numerous small files.

MS-DOS 3.0 formatted all partitions between 16 and 32 MB as FAT16. Consequently, a 20 MB hard disk formatted with MS-DOS 3.0 was not accessible by MS-DOS 2.0. Versions from MS-DOS 3.0 through 3.30 could read FAT12 partitions smaller than 15 MB but required FAT16 for larger partitions, which restricted backward compatibility. Later, starting with MS-DOS 3.31, support was restored for accessing 16–32 MB partitions formatted as FAT12.

Logical Sector-Based FAT Variants

Neither MS-DOS nor PC DOS implementations of FAT12 or FAT16 could handle partitions exceeding 32 megabytes in size. To overcome this limitation, various manufacturers developed proprietary FAT adaptations within their OEM versions of MS-DOS.

Some companies, including AST and NEC, extended the number of primary partition entries from the standard four to eight by modifying the Master Boot Record (MBR). This allowed MS-DOS to recognize and utilize multiple primary partitions.

Other vendors addressed the restriction on sector size by redefining the file system’s logical sector size to be larger than the physical sector size. These logical sectors could be as large as 8192 bytes, effectively grouping multiple 512-byte physical sectors into one logical unit. The DOS BIOS managed these logical sectors transparently based on drive geometry and partitioning information.

This strategy increased memory requirements for buffering sectors. Because earlier DOS versions were incompatible with large logical sectors, OEMs assigned unique partition type identifiers to their custom FAT variants to prevent conflicts with standard MS-DOS or PC DOS systems. Examples of these partition IDs include 0x08 for Commodore, 0x11 for Leading Edge, 0x14 for AST, 0x24 for NEC, 0x56 for AT&T, 0xE5 for Tandy, and 0xF2 for Sperry, Unisys, and Digital Research DOS Plus. Additional manufacturers such as Toshiba, Wyse, and Zenith also implemented logical sectoring.

Although these FAT variants were non-standard, they adhered to file system specifications and could often be mounted by adaptable operating systems like DR-DOS simply by recognizing their specific partition IDs. Furthermore, existing partitions using these variants could be converted into FAT12 or FAT16 volumes compatible with MS-DOS/PC DOS versions 4.0 through 6.3 by adopting a BIOS Parameter Block (BPB) with 32-bit sector counts, reducing logical sector size back to 512 bytes, and recalculating cluster and sector counts accordingly.

Simultaneously, support for multiple FAT partitions was introduced in MS-DOS/PC DOS through the extended boot record (EBR) feature in PC DOS 3.2 (1986). This enabled an extended partition to contain additional logical drives beyond the four primary partitions limit. From PC DOS 3.3 (1987) onward, multiple extended partitions allowed chaining of logical drives within the MBR framework.

Final FAT16

In November 1987, Compaq launched the FAT16B format alongside Compaq Personal Computer DOS 3.31, extending the BIOS Parameter Block (BPB) to accommodate a 32-bit sector count instead of the previous 16-bit limit. This enhancement necessitated a complete overhaul of the DOS disk driver to manage 32-bit sector addressing, a challenging task given its original development in 16-bit assembly language. Microsoft's DSKPROBE utility identifies partition type 0x06 as "BigFAT," whereas earlier versions of FDISK sometimes referred to it as "BIGDOS."

To enable support for disks exceeding 65,535 sectors, partition type 0x06 was introduced, supplanting the earlier FAT16 identifier 0x04. This change facilitated the creation of larger partitions but required updated disk drivers to operate correctly. Although FAT16B employs a 32-bit sector count in the BPB, it retains backward compatibility with the original FAT16 format.

Partitions intended for systems predating DOS 3.31 must remain below 65,536 sectors and use partition ID 0x04. Moreover, partitions marked with types 0x01 and 0x04 are constrained to reside within the initial 32 MB of the disk due to limitations present in MS-DOS 2.x.

By 1988, FAT16B support had been incorporated into DR DOS 3.31, PC DOS 4.0, OS/2 1.1, and MS-DOS 4.0. The maximum partition size was initially capped at 2 GB with standard 512-byte sectors because of an 8-bit signed sectors-per-cluster field limited to a maximum of 64 clusters (equivalent to a cluster size of 32 KB). Utilizing larger sector sizes on magneto-optical drives allowed for proportionally larger volume capacities.

Later, Windows NT expanded the maximum cluster size to 64 KB by interpreting sectors-per-cluster as an unsigned value, thereby enabling partitions up to 4 GB. However, this implementation was incompatible with other FAT variants and resulted in increased internal fragmentation. While Windows 98 SE and ME supported this format for read/write operations, they lacked comprehensive utility support, which complicated interoperability.

Prior to 1995, DOS relied exclusively on Cylinder-Head-Sector (CHS) addressing. The introduction of Logical Block Addressing (LBA) with Windows 95 (MS-DOS 7.0) enabled partitions beyond the approximate 8 GB CHS boundary. Such partitions were assigned a new type code 0x0E, known as FAT16X, which often contained inaccurate CHS geometry information within the BPB.

For both FAT12 and FAT16, root directory entries are fixed at formatting time and stored within a 16-bit field. Typically, non-floppy media allocate a default of 512 root directory entries; however, certain utilities like mkdosfs allow this number to be customized.

FAT32

To address the volume size restrictions inherent in FAT16 while preserving compatibility with DOS real-mode environments, Microsoft developed FAT32, which supports a greater number of clusters but largely reuses existing codebases. This approach increased the conventional memory usage in DOS by less than 5 KB. Cluster identifiers are represented using 32-bit values, with only 28 bits dedicated to cluster addressing.

Maximum sizes

The FAT32 boot sector contains a 32-bit field specifying total sector count, which limits the maximum volume size to approximately 2 terabytes when using standard 512-byte sectors and up to around 16 terabytes with larger sectors of 4,096 bytes. Although Windows NT’s native formatting tool restricts FAT32 volumes to a maximum of 32 gigabytes, Windows operating systems can read and write larger FAT32 partitions created through command-line tools, PowerShell scripts, third-party software, or non-Windows platforms. In August 2024, Microsoft updated Windows 11 preview versions to support FAT32 partitions up to 2 TB.

The largest possible file size on FAT32 is just under 4 gigabytes (4,294,967,295 bytes), due to the file length being stored in a four-byte field within directory entries. Similar to FAT12 and FAT16, FAT32 does not inherently support long filenames but can accommodate VFAT long filenames alongside their traditional short name equivalents.

Development

FAT32 was first introduced with Windows 95 OSR2 (MS-DOS 7.1) in 1996, necessitating reformatting to use the new file system. The release of Windows 98 included a tool designed to convert FAT16 partitions to FAT32 without risking data loss. Full native FAT32 compatibility was incorporated in Windows 2000, whereas earlier Windows NT editions depended on third-party solutions such as Winternals' FAT32 driver, which is no longer available. Starting in 1998, Caldera provided a loadable DRFAT32 driver for DR-DOS, and OEM DR-DOS 7.04 (1999) integrated built-in FAT32 support. IMS added FAT32 functionality in REAL/32 version 7.90 (1999), IBM's 4690 OS implemented it in version 2, and Ahead Software supplied a loadable FAT32.EXE driver for DR-DOS 7.03 bundled with Nero Burning ROM (2004). IBM also introduced native FAT32 support in OEM PC DOS 7.1 (1999).

There are two partition types associated with FAT32: 0x0B and 0x0C. The latter, known as FAT32X, signifies the use of LBA (Logical Block Addressing) instead of CHS (Cylinder-Head-Sector) addressing. For these partitions, CHS-related geometry fields found in the MBR and EBPB might be inaccurate or absent and should not be trusted.

Extended attributes

OS/2 makes extensive use of extended attributes (EAs), which are stored within a hidden file titled "EA␠DATA.␠SF" located in the root directory of FAT12 or FAT16 volumes. This file is referenced via reserved bytes at offset 0x14 in the file’s directory entry. In contrast, FAT32 employs these bytes to store the upper 16 bits of the starting cluster number, thereby preventing EA storage through this mechanism.

Third-party FAT32 IFS drivers, such as FAT32.IFS (version 0.70 and later) developed by Henk Kelder & Netlabs for OS/2, eComStation, and ArcaOS, manage EAs by creating additional files appended with "␠EA.␠SF" alongside the original filename. This driver marks directory entries at offset 0x0C with a special byte indicating the presence of EAs, which enhances access performance. However, this approach is incompatible with FAT32+ extensions when handling files larger than 4 GB.

Access to EAs is provided through the Workplace Shell, REXX scripting, and various graphical and command-line tools like 4OS2.

To accommodate its OS/2 subsystem, Windows NT supports EAs on HPFS, NTFS, FAT12, and FAT16 using the same format as OS/2 but lacks support for other alternate data streams found on NTFS volumes. When files containing ADS other than EAs are copied from NTFS to FAT or HPFS, warnings are generated listing the lost ADSs. Notably, Windows NT does not recognize the FAT32.IFS EA method on FAT32 partitions.

From Windows 2000 onward, the behavior remains consistent with Windows NT except that EAs are silently ignored when copying files to FAT32 partitions, although warnings still appear for other ADS types such as "Macintosh Finder Info."

The "EA␠DATA.␠SF" file format is also utilized by Cygwin to handle extended attributes.

Long file names

One of the primary objectives for Windows 95 developers was enabling support for long filenames (LFNs)—which can be up to 255 UTF-16 code units—while preserving compatibility with traditional 8.3 filenames (short filenames or SFNs). To maintain both backward and forward compatibility, LFNs were implemented as an optional extension layered over existing FAT directory structures using a workaround involving multiple directory entries.

This transparent technique for storing LFNs without modifying the underlying FAT data structures became known as VFAT ("Virtual FAT"), named after the Windows 95 virtual device driver facilitating it. Systems lacking VFAT support can access files using their SFN aliases but will lose LFN information during file copying operations.

Support for VFAT LFNs was incorporated into Windows NT starting from version 3.5. Linux distributions provide a VFAT filesystem driver that supports LFNs on FAT volumes, alongside a UVFAT driver that once combined UMSDOS-style permission handling with VFAT long filenames.

Before VFAT’s introduction, OS/2 managed long filenames on FAT using extended attributes; consequently, VFAT LFNs remain invisible within OS/2 environments, while OS/2’s EA-based LFNs are not recognized by Windows systems—necessitating manual renaming for interoperability.

Human68K utilized a proprietary variant of FAT supporting filenames up to 18 characters plus a three-character extension (18.3 format) with Shift JIS Kanji encoding.

To enable Java application compatibility, IBM's 4690 OS version 2 on FlexOS implemented a virtual filesystem architecture that stores long filenames on FAT while maintaining backward compatibility. This system presents virtual filenames (VFN) under separate logical drives while preserving access to real filenames (RFN) under their original drive letters.

Forks and alternate data streams

Although FAT lacks inherent support for alternate data streams (ADS), certain operating systems have implemented workarounds to accommodate them on FAT file systems by embedding supplementary data within files or directories or by utilizing unused FAT fields.

On Mac OS, PC Exchange manages dates, attributes, and long filenames (LFNs) through a concealed file named "FINDER.DAT", while resource forks are stored inside "RESOURCE.FRK" subfolders. Starting with PC Exchange 2.1, Mac OS stores long filenames as standard FAT LFNs; filenames exceeding 31 characters are transformed into unique 31-character names accessible to Mac applications.

macOS employs the AppleDouble format to preserve resource forks and metadata in hidden files prefixed with "._", whereas Finder maintains folder and file metadata within hidden ".DS_Store" files—even on native HFS+ volumes.

UMSDOS permissions and filenames

Early Linux versions incorporated UMSDOS, a FAT variant that recorded Unix-style file attributes such as long filenames and access permissions in a special file named "--linux-.---". With the introduction of VFAT, UMSDOS usage diminished and has been disabled by default since Linux kernel 2.5.7. Additionally, Linux provided combined support for UMSDOS-like permissions alongside VFAT long filenames through UVFAT.

FAT+

The open FAT+ specification proposed in 2007 aimed to extend FAT32 capabilities to handle files up to 256 GB minus one byte (238−1), while preserving backward compatibility with existing FAT32 volumes. However, lack of awareness of this enhancement among disk utilities and FAT32 implementations risks improper handling such as truncation or deletion of large files. Support for FAT32+ and FAT16+ remains confined to certain DR-DOS versions and is absent from mainstream operating systems. Furthermore, this extension conflicts significantly with the /EAS option used for OS/2 extended attributes on FAT32.

Turbo FAT

Within Novell's NetWare File System (NWFS), a heavily customized variant of FAT includes the Turbo FAT feature designed to enhance performance, particularly with large file operations.

FATX

FATX is a proprietary family of file systems created by Microsoft specifically for the Xbox hard drives and memory cards, first introduced in 2001.

While inspired by FAT16 and FAT32, both FATX16 and FATX32 employ simplified on-disk structures incompatible with standard FAT drivers, preventing these volumes from being mounted by conventional means.

Distinctive characteristics include a non-bootable superblock of 4 KB containing an 18-byte BPB-like structure differing from standard BPBs, cluster sizes typically set at 16 KB, only a single copy of the FAT, and directory entries sized at 64 bytes rather than the usual 32 bytes in standard FAT. Filenames can contain up to 42 OEM characters, with maximum file sizes capped at 4 GB minus one byte. Timestamps record creation, modification, and access dates but utilize a different epoch: FATX adopts January 1, 2000 (compared to January 1, 1980 in traditional FAT); on the Xbox 360 platform, the epoch reverts back to 1980.

exFAT

Introduced alongside Windows Embedded CE 6.0 in 2006 and later integrated into the Windows NT family via Windows Vista Service Pack 1 and Windows XP Service Pack 3, exFAT is a proprietary file system derived from the File Allocation Table architecture but incompatible with it. It is primarily aimed at flash storage devices such as SDXC cards and Memory Stick XC, where FAT32 remains prevalent. Manufacturers commonly pre-format SDXC cards using exFAT due to its capability to handle files larger than 4 GB—achieved through eight-byte file size fields that raise the limit to 264 − 1 bytes.

Microsoft offers both graphical user interface and command-line tools that allow formatting drives with exFAT as an alternative to NTFS, FAT16B, and FAT32. The Master Boot Record (MBR) partition type code for exFAT is 0x07, which it shares with IFS, HPFS, and NTFS partitions. The Volume Boot Record (VBR) contains logical geometry information formatted uniquely without using the traditional BPB structure.

In 2010, the exFAT specification was reverse-engineered by the SANS Institute. Subsequently, on August 28, 2019, Microsoft released the official exFAT technical documentation to facilitate its adoption in Linux and other operating systems, thereby expanding its market reach.

Patents

During the mid-1990s, Microsoft obtained multiple patents related to the long filename extensions for FAT introduced with Windows 95. These include U.S. patents 5,579,517; 5,745,902; 5,758,352; and 6,286,013, all of which expired by 2013.

On December 3, 2003, Microsoft made public its licensing terms for the FAT specification and associated intellectual property. The royalty fee was set at US$0.25 per device sold, with a maximum cap of US$250,000 per license agreement. This licensing arrangement referenced four principal FAT patents.

The EFI FAT32 specification explicitly grants certain permissions commonly interpreted as allowing operating system developers to implement FAT without violating patent rights. Additionally, other patents have influenced FAT implementations, such as U.S. patent 5,367,671 concerning OS/2 extended object attributes, which expired in 2011.

Legal disputes and challenges

In 2004, the Public Patent Foundation (PUBPAT) contested the validity of U.S. patent 5,579,517 at the USPTO, citing prior art from companies like Xerox and IBM. Initially, the USPTO rejected all claims within this patent and later invalidated U.S. patent 5,758,352 due to errors in assignee information. However, by 2006 the USPTO reversed its stance, affirming that Microsoft's implementation features for FAT were "novel and non-obvious," thereby upholding the patents.

Microsoft initiated a lawsuit against TomTom in February 2009 over alleged infringement related to VFAT long filenames. Since some TomTom devices operated on Linux, this marked Microsoft's first patent enforcement action targeting Linux-based platforms. The conflict was resolved through an out-of-court settlement wherein TomTom licensed four patents to Microsoft and ceased VFAT support, while Microsoft agreed not to pursue further litigation for five years.

In October 2010, Microsoft filed suit against Motorola for unauthorized use of multiple patents—including two VFAT-related patents—in the Android platform and lodged a complaint with the ITC. Subsequently, open source developers created alternative solutions to avoid infringing Microsoft's patents.

The European patent EP0618540 ("common name space for long and short filenames") was invalidated in Germany in 2013 and became final in 2015 following withdrawal of an appeal. This decision further limited Microsoft's ability to enforce related patents within European jurisdictions.

See also

Notes

External links

Related profiles

OOpenVMSDDigital Linear TapeAAdobe Flash PlayerCCmd.exe
Retrieved from "https://www.alfawiki.org/index.php?title=EA_DATA._SF&oldid=29079"