Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #82671

Re: Safe to Delete Photos.app?

Show all headers | View raw

On 10/8/15, 6:31 PM, in article
1mc13ek.1fayh5b1rua91jN%dempson@actrix.gen.nz, "David Empson"
<dempson@actrix.gen.nz> wrote:

...
>> Makes sense... though still would like an authoritative source. But, sure,
>> if it is accessed often seems it would almost surely be in memory.
> 
> The authoratitive source is reference to the Mac developer
> documentation, and the technical note describing the implementation of
> HFS+, which Apple no longer publishes (somewhat outdated copies can be
> found elsewhere - look for "TN1150 HFS Plus Volume Format"). I
> summarised the relevant part below.

Awesome. Thanks.

>>> Detail:
>>> 
>>> The catalog tree in HFS+ is a B*-tree sorted on a primary key of
>>> (Catalog Node ID, filename). The CNID field is a 32-bit number which
>>> uniquely identifies a file or folder within a volume.
>>> 
>>> There are two ways to locate a file within the catalog:
>>> 
>>> (a) Using the parent folder's ID, combined with the name of the file.
>>> (b) Using the file's ID.
>>> 
>>> This is implemented as two entries in the catalog tree for each file.
>>> 
>>> The first entry is the "file record". It is located using the parent
>>> folder ID and filename, so it allows the system to locate files by name.
>>> The file record holds metadata (including the file ID, date/time stamps
>>> and Finder info) and links to the file data. The sort order means that
>>> files in the same folder have adjacent entries in the catalog tree,
>>> allowing linear operations to be done in cases such as presenting a
>>> directory listing.
>>> 
>>> The second entry is a "file thread record" which is located using the
>>> file ID and points to the file record. These entries allow the system to
>>> locate a file using just the file ID. The file thread record contains a
>>> copy of the parent folder ID and filename.
>>> 
>>> Mac-native applications using standard APIs reference files using alias
>>> records (which are also stored in alias files). Alias records contain
>>> all three pieces of information: parent folder ID, filename, and file
>>> ID. Given an alias record, the system tries to locate the file first
>>> using the parent folder ID and filename (one catalog tree search). If
>>> the file has been renamed or moved, then a second catalog tree search is
>>> done using the file ID, which locates the file thread record pointing to
>>> the new parent folder ID and filename, then a third catalog tree search
>>> is used to get to the file record.
>>> 
>>> In OS X, many file search operations are done using a relative or
>>> absolute pathname, with no ID numbers known. In this case, the system
>>> parses the pathname, locates each folder in turn from the root (which
>>> has a fixed parent folder ID) or current directory, until it gets the
>>> folder ID of the target file's parent folder, then the final directory
>>> lookup gets the file record. This is exactly how it works on other file
>>> systems given a pathname.
>>> 
>>> The only case I can think of where the described scenario applies is if
>>> an application was storing file IDs to locate its files. This might
>>> happen in some POSIX applications which keep references to inode numbers
>>> rather than pathnames, but it doesn't apply to the vast majority of
>>> native Mac applications, nor to parts of the OS which understand that
>>> alias records are a more efficient method to keep track of files.
>> 
>> Maybe I am not understanding, but most Mac programs are not path-based
>> though. I can move and re-name a file and the program still can find it in
>> its "Open Recent" menu, for example.
> 
> The path-based ones are typically lower level parts of the system using
> text paths in config files, e.g. things like launchd.
> 
> Most Mac GUI applications which store references to files do so using
> alias records: the open file dialog returns an alias record, which is
> passed to subsequent APIs to open and otherwise manipulate the file.
> 
> Open Recent should store alias records as a blob in the application
> preference file. The structure of the alias record is private to the
> system, but APIs are available to derive information such as pathnames.
> 
> If the application stores a pathname instead of an alias record, then
> its "Open Recent" entry will break if the file is renamed or moved. An
> alias record allows the file to be tracked as long as it remains on the
> same volume.
> 
> If the application went to the trouble of getting the file ID and stored
> that instead of the alias record, it would break if the file was deleted
> and replaced with a new file with the same name in the same folder.
> 
> Assuming the application has an alias record, then as I described above,
> a single catalog tree lookup is required to access the file (using the
> parent folder ID and filename stored in the alias record).
> 
> If the file has been moved (within the volume) or renamed, then three
> catalog tree lookups are required - the failed attempt using the old
> parent/filename, then a file ID lookup to get the new parent/filename
> (which updates the alias record), then opening the file with the new
> parent/filename.

Thanks. Sincerely appreciate it.

-- 
* OS X / Linux: What is a file?     <http://youtu.be/_dMbXGLW9PI>
* Mint MATE Trash, Panel, Menu:     <http://youtu.be/C0y74FIf7uE>
* Mint KDE working with folders:    <http://youtu.be/7C9nvniOoE0>
* Mint KDE creating files:          <http://youtu.be/N7-fZJaJUv8>
* Mint KDE help:                    <http://youtu.be/3ikizUd3sa8>
* Mint KDE general navigation:      <http://youtu.be/t9y14yZtQuI>
* Mint KDE bugs or Easter eggs?     <http://youtu.be/CU-whJQvtfA>
* Easy on OS X / Hard on Linux:     <http://youtu.be/D3BPWANQoIk>
* OS / Word Processor Comparison:   <http://youtu.be/w6Qcl-w7s5c>

Back to comp.sys.mac.system | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Safe to Delete Photos.app? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-10-07 00:41 -0400
  Re: Safe to Delete Photos.app? Huge <Huge@nowhere.much.invalid> - 2015-10-08 02:15 +0000
    Re: Safe to Delete Photos.app? Snit <usenet@gallopinginsanity.com> - 2015-10-07 19:41 -0700
      Re: Safe to Delete Photos.app? Huge <Huge@nowhere.much.invalid> - 2015-10-08 02:58 +0000
        Re: Safe to Delete Photos.app? Snit <usenet@gallopinginsanity.com> - 2015-10-07 20:44 -0700
          Re: Safe to Delete Photos.app? Huge <Huge@nowhere.much.invalid> - 2015-10-09 03:57 +0000
            Re: Safe to Delete Photos.app? Snit <usenet@gallopinginsanity.com> - 2015-10-08 21:04 -0700
            Re: Safe to Delete Photos.app? nospam <nospam@nospam.invalid> - 2015-10-09 01:51 -0400
              Re: Safe to Delete Photos.app? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2015-10-09 06:27 +0000
                Re: Safe to Delete Photos.app? Huge <Huge@nowhere.much.invalid> - 2015-10-09 14:31 +0000
                Re: Safe to Delete Photos.app? Jolly Roger <jollyroger@pobox.com> - 2015-10-09 17:38 +0000
                Re: Safe to Delete Photos.app? Alan Browne <alan.browne@freelunchvideotron.ca> - 2015-10-09 13:49 -0400
                Re: Safe to Delete Photos.app? Jolly Roger <jollyroger@pobox.com> - 2015-10-09 18:06 +0000
                Re: Safe to Delete Photos.app? Alan Browne <alan.browne@freelunchvideotron.ca> - 2015-10-09 15:15 -0400
                Re: Safe to Delete Photos.app? FPP <fredp151@gmail.com> - 2015-10-09 15:21 -0400
                Re: Safe to Delete Photos.app? Huge <Huge@nowhere.much.invalid> - 2015-10-11 16:32 +0000
      Re: Safe to Delete Photos.app? nospam <nospam@nospam.invalid> - 2015-10-07 23:00 -0400
        Re: Safe to Delete Photos.app? Snit <usenet@gallopinginsanity.com> - 2015-10-07 21:01 -0700
          Re: Safe to Delete Photos.app? nospam <nospam@nospam.invalid> - 2015-10-08 00:13 -0400
            Re: Safe to Delete Photos.app? Snit <usenet@gallopinginsanity.com> - 2015-10-08 08:57 -0700
              Re: Safe to Delete Photos.app? nospam <nospam@nospam.invalid> - 2015-10-08 12:19 -0400
                Re: Safe to Delete Photos.app? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-10-08 13:44 -0400
                Re: Safe to Delete Photos.app? nospam <nospam@nospam.invalid> - 2015-10-08 13:54 -0400
                Re: Safe to Delete Photos.app? Snit <usenet@gallopinginsanity.com> - 2015-10-08 11:05 -0700
                Re: Safe to Delete Photos.app? nospam <nospam@nospam.invalid> - 2015-10-08 14:11 -0400
                Re: Safe to Delete Photos.app? Snit <usenet@gallopinginsanity.com> - 2015-10-08 11:23 -0700
                Re: Safe to Delete Photos.app? Jolly Roger <jollyroger@pobox.com> - 2015-10-08 20:25 +0000
                Re: Safe to Delete Photos.app? Snit <usenet@gallopinginsanity.com> - 2015-10-08 16:41 -0700
                Re: Safe to Delete Photos.app? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-10-08 14:28 -0400
                Re: Safe to Delete Photos.app? nospam <nospam@nospam.invalid> - 2015-10-08 14:31 -0400
                Re: Safe to Delete Photos.app? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-10-08 16:09 -0400
                Re: Safe to Delete Photos.app? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2015-10-08 22:27 +0000
                Re: Safe to Delete Photos.app? dempson@actrix.gen.nz (David Empson) - 2015-10-09 12:09 +1300
                Re: Safe to Delete Photos.app? Snit <usenet@gallopinginsanity.com> - 2015-10-08 17:06 -0700
                Re: Safe to Delete Photos.app? dempson@actrix.gen.nz (David Empson) - 2015-10-09 14:31 +1300
                Re: Safe to Delete Photos.app? Snit <usenet@gallopinginsanity.com> - 2015-10-08 19:06 -0700
    Re: Safe to Delete Photos.app? nospam <nospam@nospam.invalid> - 2015-10-07 23:00 -0400
    Re: Safe to Delete Photos.app? Jolly Roger <jollyroger@pobox.com> - 2015-10-08 17:26 +0000

csiph-web