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

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

Re: Safe to Delete Photos.app?

Show all headers | View raw

On 10/8/15, 4:09 PM, in article 1mc0rrh.wut1lxb7e5mjN%dempson@actrix.gen.nz,
"David Empson" <dempson@actrix.gen.nz> wrote:

> Snit <usenet@gallopinginsanity.com> wrote:
> 
>> On 10/8/15, 9:19 AM, in article 081020151219390019%nospam@nospam.invalid,
>> "nospam" <nospam@nospam.invalid> wrote:
>> 
>>> In article <D23BE07D.5F7C8%usenet@gallopinginsanity.com>, Snit
>>> <usenet@gallopinginsanity.com> wrote:
>>> 
>>>>>>>> But, yes, HFS+ is outdated and it would be good to have it be replaced.
>>>>>>> 
>>>>>>> it's been updated over the years and works just fine.
>>>>>> 
>>>>>> I am FAR from an expert on file systems... but know it does not
>>>>>> handle many of the features of ZFS and the like such as block level
>>>>>> backups and checksums for integrity. Also recall something about it
>>>>>> not being able to handle requests as efficiently as NTFS, ext4, and
>>>>>> the like - but cannot go into detail or even be certain about that
>>>>>> without Googling.
>>>>> 
>>>>> hfs was never intended to be like zfs, which has its share of issues
>>>>> too.
>>>> 
>>>> Fair enough... but if it is true that it needs to do far more reads and
>>>> seeks and the like than it should then that slows it down.
>>> 
>>> hfs doesn't need to do more reads and seeks than any other file system.
>>> whoever said that is clueless.
>> 
>> Not at all an expert in this area and do not vouch for what I found but here
>> it is:
>> 
>>   <http://rixstep.com/2/20031102,00.shtml>
>>     -----
>>     Every disk access on OS X goes to disk twice. At least twice.
>>     That's right: accessing a file under OS X is slow. It has to be.
>>     ...
>>     The implication of this 'caveat' is that a disk access in Mac OS X
>>     requires at least two searches through the catalog file tree: the
>>     first to determine the parent folder's CNID (this can be
>>     recursive), and the second (or final) to find the file once the
>>     CNID of the parent folder can be concatenated with the file name.
>>     -----
>> 
>> Would love to see contrary information.
> 
> The double search in the catalog tree is true in the case where a file
> needs to be located using its file ID. Where it goes wrong is that this
> is not the usual method of finding a file.
> 
> Even when this method does need to be used, the catalog tree is probably
> cached in memory, so it wouldn't involve two disk accesses.

Makes sense... though still would like an authoritative source. But, sure,
if it is accessed often seems it would almost surely be in memory.

> 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.


-- 
* 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