Wilfredo Sanchez, Apple Computer
:
') and UFS (slash, '/
').This also means that HFS+ file names may contain the slash characterand not colons, while the opposite is true for UFS file names. Thiswas easy to address, though it involves transforming strings back andforth. The HFS+ implementation in the kernel's VFS layer convertscolon to slash and vice versa when reading from and writing to theon-disk format. So on disk, the separator is a colon, but at the VFSlayer (and therefore anything above it and the kernel, such as libc)it's a slash. However, the traditional Mac OS toolkits expect colons,so above the BSD layer, the core Carbon toolkit does yet anothertranslation. The result is that Carbon applications see colons, andeveryone else sees slashes. This can create a user-visibleschizophrenia in the rare cases of file names containing coloncharacters, which appear to Carbon applications as slash characters,but to BSD programs and Cocoa applications as colons.open()
them. One was to combine thetwo streams into AppleDouble format. This has the advantage ofcontaining all of the data in the complex file, and programs likecp
could work properly. The problem then is that if onewere to open a complex C source file in emacs they'd see not only theprogram text, but also some weird encoding information and whateverresource data that was put there by a Carbon application. A fatalproblem with this scheme is that part of the file data (the encodinginfo) is creates by the filesystem, and isn't really part of the filedata, and should therefore not be editable. The non-lossy aspect ofthis solution is what drew us to is, but the complications turned outto be too substantial.foo/bar
' gets you the data for file bar, but'foo/bar/.namedfork/resource
' will get you the resourcefork for bar. (The actual appended string may change.) Note that thefile is not somehow acting as a directory; it is not listable, andstat()
calls still show it as a file. This mechanism canbe carried to other filesystems with complex files, such as UDF. (UDFalso has allows attributes for directories.)cp foo bar
' will resultin a new file bar which is missing the resource data from foo (ifthere was any). Backup and archiving software may also lose data. Westill have the problem of sharing files with systems that don'tsupport complex files. Mac OS X will continue to support complexfiles, but we are moving away from their use in order to increase ourability to operate in a heterogeneous environment.foo
', written by a MacOS client is viewed from the Unix side, there is another file (usuallynamed in a convention similar to '.foo.resource
' or'.resources/foo>
') which contains the resource data. Ifthese servers are also serving Unix clients (including local access),which is often the case, files tend to get moved around in the Unixside, and the resource file is left in the old location. The resultis an effective loss of the resource data and a need somehow to manage(periodically clean up) these disassociate resource files. The HFS+filesystem can probably address this problem by magically moving theresource file along with the data, but strange behavior of this sorttends to produce bugs, and this approach didn't seem to offersignificant advantages over the alternatives, and it got dropped.delete()
system call was added to BSD so that we have both semantics available.Typically, Unix programs will call unlink()
and Carbonapplications will call delete()
. An unlink will alwayssucceed, so it is still possible for a Carbon application which has afile open to lose that file when it is closed, if a BSD programunlinked it. This is acceptable because the goal is to allow Carbonprograms to continue to cooperate with each other as designed, and BSDprograms don't usually delete files belonging to a Carbon program, sothe software tends to work as expected. Castle fireball defense mac os.0
(root) and group 0
(wheel) are reasonable defaults, but afile mode of 0000
is almost certainly not what the userwants. Fortunately, we are able to distinguish between 'no meta-dataset' and zero values for mode and owner info. What we do in this caseis present the owner, group, and mode as some reasonable default,which is determined by examining the permissions on the directory nodeon which the filesystem is mounted. Note that the actual permissionson disk remain unset unless someone sets them explicitly; an unmountand remount with a different default will effect the mode of suchfiles. This allows for a flexible administration of the default modesuch that some disk default to more open permissions than others, asdesired.make
command, which uses whitespace as a file namedelimiter, making it difficult to produce program output called, forexample, Netscape Navigator®
. There is no reason whythis has to be the case, but it is an unfortunate historical artifactof how Unix grew up.sh
program does not exist in /bin
, the system won't evenboot properly. While Mac OS is not immune from such problems, it doesallow the user to relocate or rename even such important items as theSystem Folder. This is a particularly significant issue because,although we use BSD as the core system software, we do not want torequire our users to understand how BSD works. Ideally, the typicalMacintosh user does not even know that BSD is there. The verypresence of such folders as 'usr
' and 'etc
'on disk is therefore awkward, and we hide those directories and theircontents at the application level in order to avoid confusion as towhy they are there and cannot be moved or deleted. One idea is to putall system files into a Mac OS-style System Folder, and make thatfolder opaque to the user. This requires that there be other methodsfor managing the system software than allowing users to poke in therethemselves, and we still have the problem that standard Unix paths arerequired to exist at the root level of the boot volume. This is stillan area which we are actively working to improve upon./usr/bin
, the icons in /usr/share/photoshop
,the plug-ins in /usr/libexec
, and so on. While it hascertain advantages, the problem with this approach is that files arescattered around the disk, making it somewhat difficult to install anduninstall software. This is addressable by using a package installerscheme with receipts and so on, but that is easily broken if the useruses different installers or bypasses the installer by unrolling a tararchive./usr/include
, libraries in/usr/lib
, and additional resources wherever they go, wecreate a single framework bundle which encapsulates everything neededfor that library. The compiler knows how to find specific files inthe framework, because each type of bundle has a well-definedstructure.chgrp()
calls are ignored. Ignore setuid bits. This is similar the the behavior of DOS filesystems or HFS (not HFS+) volumes, which don't have any storage for users and groups anyway. chmod()
and chgrp()
settings will stick. https://www.mit.edu/people/wsanchez/papers/USENIX_2000/
.