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

Groups > comp.sys.mac.system > #79900 > unrolled thread

TM drive full?

Back to article view | Back to comp.sys.mac.system

Contents

  TM drive full? RonTheGuy@null.invalid (Ron) - 2015-09-17 18:57 -0700
    Re: TM drive full? nospam <nospam@nospam.invalid> - 2015-09-17 22:18 -0400
    Re: TM drive full? dempson@actrix.gen.nz (David Empson) - 2015-09-18 14:18 +1200
      Re: TM drive full? RonTheGuy@null.invalid (Ron) - 2015-09-17 20:35 -0700
      Re: TM drive full? Martin Frost me at invalid stanford daht edu <nospam@stanford.edu.invalid> - 2015-09-18 03:08 -0700
        Re: TM drive full? dempson@actrix.gen.nz (David Empson) - 2015-09-18 22:42 +1200
          Re: TM drive full? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-09-18 12:21 -0400
            Re: TM drive full? dempson@actrix.gen.nz (David Empson) - 2015-09-19 10:27 +1200
              Re: TM drive full? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-09-18 18:58 -0400
                Re: TM drive full? dempson@actrix.gen.nz (David Empson) - 2015-09-19 12:59 +1200
                  Re: TM drive full? Barry Margolin <barmar@alum.mit.edu> - 2015-09-18 21:14 -0400
                    Re: TM drive full? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-09-18 21:20 -0400
                      Re: TM drive full? dempson@actrix.gen.nz (David Empson) - 2015-09-19 14:55 +1200
                      Re: TM drive full? nospam <nospam@nospam.invalid> - 2015-09-18 22:56 -0400
                        Re: TM drive full? Barry Margolin <barmar@alum.mit.edu> - 2015-09-19 17:04 -0400
                          Re: TM drive full? nospam <nospam@nospam.invalid> - 2015-09-19 17:24 -0400
                            Re: TM drive full? Barry Margolin <barmar@alum.mit.edu> - 2015-09-19 22:08 -0400
                              Re: TM drive full? nospam <nospam@nospam.invalid> - 2015-09-19 22:14 -0400
                  Re: TM drive full? Jolly Roger <jollyroger@pobox.com> - 2015-09-19 01:21 +0000
                    Re: TM drive full? dempson@actrix.gen.nz (David Empson) - 2015-09-19 14:55 +1200
                      Re: TM drive full? Jolly Roger <jollyroger@pobox.com> - 2015-09-19 03:50 +0000
        Re: TM drive full? Jolly Roger <jollyroger@pobox.com> - 2015-09-18 19:23 +0000

Page 1 of 2  [1] 2  Next page →

#79900 — TM drive full?

I have a 1-TB USB drive that I use for occasional TM backups. It's split
into four partitions. Backed up the iMac last night; TM displayed a
message that the drive was full, and that it had deleted one or more old
backups to make room for new. I did Get Info on that partition; it had
over 60 GB free; why did TM say it was full? 

-- 
_____________________________
Ron, the humblest guy in town

[toc] | [next] | [standalone]

#79901

In article <1mawpuq.1tx2r4c1v4hbv0N%RonTheGuy@null.invalid>, Ron
<RonTheGuy@null.invalid> wrote:

> I have a 1-TB USB drive that I use for occasional TM backups. It's split
> into four partitions. Backed up the iMac last night; TM displayed a
> message that the drive was full, and that it had deleted one or more old
> backups to make room for new. I did Get Info on that partition; it had
> over 60 GB free; why did TM say it was full?

because it wanted more than 60g for a snapshot even if it ended up
using less.

[toc] | [prev] | [next] | [standalone]

#79902

Ron <RonTheGuy@null.invalid> wrote:

> I have a 1-TB USB drive that I use for occasional TM backups. It's split
> into four partitions. Backed up the iMac last night; TM displayed a
> message that the drive was full, and that it had deleted one or more old
> backups to make room for new. I did Get Info on that partition; it had
> over 60 GB free; why did TM say it was full? 

TM does an initial estimate of how much space is required for a backup.
That estimate is a worst case, based on all folders which contain any
changes since the last backup, assuming the previous backup will be
retained.

If the worst case backup won't fit, then TM starts deleting old backups
until there is enough space for the worst case.

Once it has enough free space, TM can do the backup, and in the process
it often finds that less space was needed, due to being able to share
some unchanged files with the most recent backup.

The end result is that you have a fairly large chunk of free space.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#79903

David Empson <dempson@actrix.gen.nz> wrote:

> Ron <RonTheGuy@null.invalid> wrote:
> 
> > I have a 1-TB USB drive that I use for occasional TM backups. It's split
> > into four partitions. Backed up the iMac last night; TM displayed a
> > message that the drive was full, and that it had deleted one or more old
> > backups to make room for new. I did Get Info on that partition; it had
> > over 60 GB free; why did TM say it was full? 
> 
> TM does an initial estimate of how much space is required for a backup.
> That estimate is a worst case, based on all folders which contain any
> changes since the last backup, assuming the previous backup will be
> retained.
> 
> If the worst case backup won't fit, then TM starts deleting old backups
> until there is enough space for the worst case.
> 
> Once it has enough free space, TM can do the backup, and in the process
> it often finds that less space was needed, due to being able to share
> some unchanged files with the most recent backup.
> 
> The end result is that you have a fairly large chunk of free space.
Great explanation. Thanks, DE. 

-- 
_____________________________
Ron, the humblest guy in town

[toc] | [prev] | [next] | [standalone]

#79904

dempson@actrix.gen.nz (David Empson) writes:

> Ron <RonTheGuy@null.invalid> wrote:
> 
> > I have a 1-TB USB drive that I use for occasional TM backups. It's split
> > into four partitions. Backed up the iMac last night; TM displayed a
> > message that the drive was full, and that it had deleted one or more old
> > backups to make room for new. I did Get Info on that partition; it had
> > over 60 GB free; why did TM say it was full? 
> 
> TM does an initial estimate of how much space is required for a backup.
> That estimate is a worst case, based on all folders which contain any
> changes since the last backup, assuming the previous backup will be
> retained.

David, are you saying that TM's worst case assumes that all files in
any changed folder will need to be backed up?

Martin

[toc] | [prev] | [next] | [standalone]

#79905

Martin Frost me at invalid stanford daht edu
<nospam@stanford.edu.invalid> wrote:

> dempson@actrix.gen.nz (David Empson) writes:
> 
> > Ron <RonTheGuy@null.invalid> wrote:
> > 
> > > I have a 1-TB USB drive that I use for occasional TM backups. It's split
> > > into four partitions. Backed up the iMac last night; TM displayed a
> > > message that the drive was full, and that it had deleted one or more old
> > > backups to make room for new. I did Get Info on that partition; it had
> > > over 60 GB free; why did TM say it was full? 
> > 
> > TM does an initial estimate of how much space is required for a backup.
> > That estimate is a worst case, based on all folders which contain any
> > changes since the last backup, assuming the previous backup will be
> > retained.
> 
> David, are you saying that TM's worst case assumes that all files in
> any changed folder will need to be backed up?

That's educated guesswork on my part, based on the mechanism TM uses to
identify files changed since the last backup: the system keeps a log of
folders in which something has changed, not individual files.

The other evidence is that when TM starts doing the backup and reports
progress e.g. 100 MB of 3.5 GB, the second number (estimated backup
size) is often a substantial overestimate: I've observed many cases
where TM stops backing up well before it reaches that total.

I can't think of any reasonable explanation for this behaviour other
than TM delaying its detailed comparison with the previous backup until
it has actually started copying files. If the folder contains a mixture
of modified files and large unmodified files, the unmodified ones only
need a hard link created rather than having to be completely copied,
which is a lot faster.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#79906

On 15-09-18 06:42, David Empson wrote:

> That's educated guesswork on my part, based on the mechanism TM uses to
> identify files changed since the last backup: the system keeps a log of
> folders in which something has changed, not individual files.

If TM works at the HFS level, are there really "folders" since the
catalogue file is "flat" ?  Besides, each individual file has a last
mofified date, so TM can scan through the catalogue for files that were
modified since last TM run.

(On VMS, there is a "last backup" date on files so you can easily get
all files mofified since last time it was backed up).



> The other evidence is that when TM starts doing the backup and reports
> progress e.g. 100 MB of 3.5 GB, the second number (estimated backup
> size) is often a substantial overestimate: 

Depends on the file system. Does the catalogue file contain the
"actually used" number of bytes or only "allocated" ?

If the catalogue file contains only the number of allocated blocks, then
TM might be way too slow if it had to go into each file to get the
number of bytes actually used to build its estimate. Would be much
faster to just scan the catalogue file to bubild list of files to be
backed up and how large they are.

Then, as it actually backs up files, it would only backup the number of
bytes actually used in a file which can be different from bytes allocated.

Another possible difference: since TM only backsup changes to a file,
the estimate may yield the full file, but once TM compares the previous
backup to the current file, it may decide it only has to backup changed
2 lines of text on a 20 megabyte document.

[toc] | [prev] | [next] | [standalone]

#79911

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 15-09-18 06:42, David Empson wrote:
> 
> > That's educated guesswork on my part, based on the mechanism TM uses to
> > identify files changed since the last backup: the system keeps a log of
> > folders in which something has changed, not individual files.
> 
> If TM works at the HFS level, are there really "folders" since the
> catalogue file is "flat" ?

What on earth gave you that idea? The HFS/HFS+ catalog is a B*-tree. The
indivdidual file/folder records are stored in leaf nodes, with the tree
forming an index with the key being (unique_id, filename). There are two
entries for each file: one allows locating a file by its parent folder
ID and filename, the other allows finding a file by its ID (with no
filename). The individual file records refer back to the parent folder
ID, and the root directory has a fixed parent folder ID (with a field in
the volume header to locate the root directory). Linear scanning of leaf
nodes can be used to produce a list of files in the same folder (sorted
in alphabetic order).

The mechanism TM uses to do its initial scan for changes is not part of
HFS. The system has an fseventd process which records file system
changes in a timestamped log which lives in the ".fseventd" folder at
the root level of the drive. The changes are recorded at folder level,
not individual files.

This allows TM to quickly locate folders that have any changes after a
particular time.

If the fsevent database is damaged or out of sync then TM has to scan
the entire file system, which takes a lot longer. I think TM calls this
a deep traversal or similar.

> Besides, each individual file has a last mofified date, so TM can scan
> through the catalogue for files that were modified since last TM run.

It could, but it appears that there are at least some cases where it
doesn't, hence the overestimate of space requirements.

> (On VMS, there is a "last backup" date on files so you can easily get
> all files mofified since last time it was backed up).

That wouldn't be useful because TM can back up to multiple destinations.
The point of reference is when it was last backed up to a particular
destination, which requires looking at the timestamp of the backup.

> > The other evidence is that when TM starts doing the backup and reports
> > progress e.g. 100 MB of 3.5 GB, the second number (estimated backup
> > size) is often a substantial overestimate: 
> 
> Depends on the file system. Does the catalogue file contain the
> "actually used" number of bytes or only "allocated" ?

The catalog records the nominal size of the file in bytes. Allocation to
disk blocks is handled via a separate structure which manages extents
(consecutive runs of blocks allocated to files). The first few extents
for a file are stored in the catalog, with the rest going to an extent
overflow tree (indexed by the file ID). All of these structures can be
accssed quickly to add up actual used space for a file.

There are very few "sparse" files on most systems, so TM skipping the
calculation of disk space is not a reasonable explanation for the
observed behaviour. (The only obvious example is sparse disk images, not
including sparse bundles.)

> If the catalogue file contains only the number of allocated blocks, then
> TM might be way too slow if it had to go into each file to get the
> number of bytes actually used to build its estimate. Would be much
> faster to just scan the catalogue file to bubild list of files to be
> backed up and how large they are.
> 
> Then, as it actually backs up files, it would only backup the number of
> bytes actually used in a file which can be different from bytes allocated.
> 
> Another possible difference: since TM only backsup changes to a file,
> the estimate may yield the full file, but once TM compares the previous
> backup to the current file, it may decide it only has to backup changed
> 2 lines of text on a 20 megabyte document.

That dosn't happen. TM always backs up full files, even if only a single
byte has changed.

HFS+ doesn't have the data structures required to splice data within
files so that a copy can be hard linked but with a segment replaced.
More advanced file systems like ZFS can do this sort of thing.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#79915

On 15-09-18 18:27, David Empson wrote:

> What on earth gave you that idea? The HFS/HFS+ catalog is a B*-tree.

Sorry my bad. Was thinking about the whole catalogue being a single file
and wrongly interpreted this as a flat file.

When you say there are 2 entries for each file, would it be correct to
state that one of those is just a pointer to the other ?  (so if you
chjange file attributes, only once record needs to be updated).


> The mechanism TM uses to do its initial scan for changes is not part of
> HFS. The system has an fseventd process which records file system
> changes in a timestamped log which lives in the ".fseventd" 

But when I change a file, its "real" modification time stamp in the file
header is also modified, right ?

or are dates given by "ls" drawn from the .fseventsd subsystem ?

> This allows TM to quickly locate folders that have any changes after a
> particular time.

But then TM has to go into the catalogue file to scan through files
inside such a folder to see which ones were modified since last TM
backup, correct ?

> That wouldn't be useful because TM can back up to multiple destinations.
> The point of reference is when it was last backed up to a particular
> destination, which requires looking at the timestamp of the backup.

Fair enough. On VMS , you can /since=backup  which selects any file
where "last backup date" is smaller than "last modified date".

When TM would be doing is to get an absolute date time from last backup
and then select all files where "last modified date" is greater than
<absolute date>

> The catalog records the nominal size of the file in bytes.

Ok, so the catalogue has the exact file size in bytes, so when file size
< than allcated size, it would not explain discrepancy.

> There are very few "sparse" files on most systems, so TM skipping the
> calculation of disk space is not a reasonable explanation for the
> observed behaviour. (The only obvious example is sparse disk images, not
> including sparse bundles.)

On VMS there are files maked "/nobackup". For instrance, page/swap
files. BACKUP will record the file attributes, but not the data in them.
So the files can be recrated with exact same attributes and allocation,
but contain no data.

This means that while initially thinking it will have to backup a large
file, it turns out only the file header is written to the output backup.

Could the same happen on OS-X where some files (temporary, page files
etc) are marked in the same way and only the file attributes are kept
and none of their data is preserved ?




> That dosn't happen. TM always backs up full files, even if only a single
> byte has changed.

I was under the impression that the "versions" (Lion and later as I
recall) simply deployed TM technology that backed up only changed
portions of files to same on backup size. That would imply that TM only
saves changed portions of files, no ?

[toc] | [prev] | [next] | [standalone]

#79926

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 15-09-18 18:27, David Empson wrote:
> 
> > What on earth gave you that idea? The HFS/HFS+ catalog is a B*-tree.
> 
> Sorry my bad. Was thinking about the whole catalogue being a single file
> and wrongly interpreted this as a flat file.
> 
> When you say there are 2 entries for each file, would it be correct to
> state that one of those is just a pointer to the other ?  (so if you
> chjange file attributes, only once record needs to be updated).

Yes. I'd have to read the technote again to refresh my memory on how it
is implemented.

> > The mechanism TM uses to do its initial scan for changes is not part of
> > HFS. The system has an fseventd process which records file system
> > changes in a timestamped log which lives in the ".fseventd" 
> 
> But when I change a file, its "real" modification time stamp in the file
> header is also modified, right ?
> 
> or are dates given by "ls" drawn from the .fseventsd subsystem ?

File modification times are in the catalog entry for the file.

fseventsd is used by TM, various other system components, and is
available to applications via an API as a method for quickly locating
folders which contain changed files. It wouldn't work for file
modification times because it doesn't list files, only folders.

> > This allows TM to quickly locate folders that have any changes after a
> > particular time.
> 
> But then TM has to go into the catalogue file to scan through files
> inside such a folder to see which ones were modified since last TM
> backup, correct ?

Yes. The question is when it does that.

Locating the first file in the modified folder is an index lookup, after
which it can linearly process leaf nodes to get all catalog entries for
files in the folder.

> > That wouldn't be useful because TM can back up to multiple destinations.
> > The point of reference is when it was last backed up to a particular
> > destination, which requires looking at the timestamp of the backup.
> 
> Fair enough. On VMS , you can /since=backup  which selects any file
> where "last backup date" is smaller than "last modified date".
> 
> When TM would be doing is to get an absolute date time from last backup
> and then select all files where "last modified date" is greater than
> <absolute date>
> 
> > The catalog records the nominal size of the file in bytes.
> 
> Ok, so the catalogue has the exact file size in bytes, so when file size
> < than allcated size, it would not explain discrepancy.
> 
> > There are very few "sparse" files on most systems, so TM skipping the
> > calculation of disk space is not a reasonable explanation for the
> > observed behaviour. (The only obvious example is sparse disk images, not
> > including sparse bundles.)
> 
> On VMS there are files maked "/nobackup". For instrance, page/swap
> files. BACKUP will record the file attributes, but not the data in them.
> So the files can be recrated with exact same attributes and allocation,
> but contain no data.
> 
> This means that while initially thinking it will have to backup a large
> file, it turns out only the file header is written to the output backup.
> 
> Could the same happen on OS-X where some files (temporary, page files
> etc) are marked in the same way and only the file attributes are kept
> and none of their data is preserved ?

In most cases, files in that category are not backed up because TM
completely skips the folder containing them.

> > That dosn't happen. TM always backs up full files, even if only a single
> > byte has changed.
> 
> I was under the impression that the "versions" (Lion and later as I
> recall) simply deployed TM technology that backed up only changed
> portions of files to same on backup size. That would imply that TM only
> saves changed portions of files, no ?

Versions is a different mechanism with a substantially different
implementation, based around an SQLite database with associated files or
partial files.

A TM backup contains complete files which can be copied by Finder with
no special tricks (the only special feature is hard links, which are
implemented at the file system level).

The Versions mechanism requires the original file to be reconstructed
which can only be done through the special user interface.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#79928

In article <1mazyfa.1j974q111p7q21N%dempson@actrix.gen.nz>,
 dempson@actrix.gen.nz (David Empson) wrote:

> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> > On VMS there are files maked "/nobackup". For instrance, page/swap
> > files. BACKUP will record the file attributes, but not the data in them.
> > So the files can be recrated with exact same attributes and allocation,
> > but contain no data.
> > 
> > This means that while initially thinking it will have to backup a large
> > file, it turns out only the file header is written to the output backup.
> > 
> > Could the same happen on OS-X where some files (temporary, page files
> > etc) are marked in the same way and only the file attributes are kept
> > and none of their data is preserved ?
> 
> In most cases, files in that category are not backed up because TM
> completely skips the folder containing them.

To expand on this, in the Time Machine preferences there's a list of 
items not to back up. You can list individual files, or whole folders, 
partitions, or drives.

And TM also has a built-in set of exclusions, such as standard cache 
folders.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#79932

On 15-09-18 21:14, Barry Margolin wrote:

> And TM also has a built-in set of exclusions, such as standard cache 
> folders.

But if you reconstruct a disk from backup, are those files recreated
(empty but allocated) or will they be missing from the reconstructed
drive ?

Yeah, certain files get created dynamically. Just wondering if there
exists a mechanism to backup just file attributes, not its contents.

[toc] | [prev] | [next] | [standalone]

#79937

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 15-09-18 21:14, Barry Margolin wrote:
> 
> > And TM also has a built-in set of exclusions, such as standard cache
> > folders.
> 
> But if you reconstruct a disk from backup, are those files recreated
> (empty but allocated) or will they be missing from the reconstructed
> drive ?

Cache files, folders, swap files, etc. are recreated automatically by
the system if they don't exist. The same situation applies in a new OS
installation.

> Yeah, certain files get created dynamically. Just wondering if there
> exists a mechanism to backup just file attributes, not its contents.

No. Cache files and similar simply don't exist in the backup.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#79939

In article <55fcb849$0$65283$c3e8da3$e074e489@news.astraweb.com>, JF
Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> > And TM also has a built-in set of exclusions, such as standard cache 
> > folders.
> 
> But if you reconstruct a disk from backup, are those files recreated
> (empty but allocated) or will they be missing from the reconstructed
> drive ?

they're never copied and therefore never restored.

[toc] | [prev] | [next] | [standalone]

#79986

In article <180920152256300223%nospam@nospam.invalid>,
 nospam <nospam@nospam.invalid> wrote:

> In article <55fcb849$0$65283$c3e8da3$e074e489@news.astraweb.com>, JF
> Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
> > > And TM also has a built-in set of exclusions, such as standard cache 
> > > folders.
> > 
> > But if you reconstruct a disk from backup, are those files recreated
> > (empty but allocated) or will they be missing from the reconstructed
> > drive ?
> 
> they're never copied and therefore never restored.

I thought he meant the empty folders where the files will be stored on 
the new disk.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#79988

In article <barmar-0DD1D4.17040219092015@88-209-239-213.giganet.hu>,
Barry Margolin <barmar@alum.mit.edu> wrote:

> > > > And TM also has a built-in set of exclusions, such as standard cache 
> > > > folders.
> > > 
> > > But if you reconstruct a disk from backup, are those files recreated
> > > (empty but allocated) or will they be missing from the reconstructed
> > > drive ?
> > 
> > they're never copied and therefore never restored.
> 
> I thought he meant the empty folders where the files will be stored on 
> the new disk.

doesn't matter.

excluding a folder means just that, the folder and all of its contents
are not backed up, so there's nothing to restore.

excluding the *contents* of the folder but *not* the folder itself will
result in an empty folder being copied, which will then be restored as
empty, but that's not what is normally done and you can't guarantee
that something not excluded is later added to the folder anyway which
would be backed up.

[toc] | [prev] | [next] | [standalone]

#80010

In article <190920151724238569%nospam@nospam.invalid>,
 nospam <nospam@nospam.invalid> wrote:

> In article <barmar-0DD1D4.17040219092015@88-209-239-213.giganet.hu>,
> Barry Margolin <barmar@alum.mit.edu> wrote:
> 
> > > > > And TM also has a built-in set of exclusions, such as standard cache 
> > > > > folders.
> > > > 
> > > > But if you reconstruct a disk from backup, are those files recreated
> > > > (empty but allocated) or will they be missing from the reconstructed
> > > > drive ?
> > > 
> > > they're never copied and therefore never restored.
> > 
> > I thought he meant the empty folders where the files will be stored on 
> > the new disk.
> 
> doesn't matter.
> 
> excluding a folder means just that, the folder and all of its contents
> are not backed up, so there's nothing to restore.
> 
> excluding the *contents* of the folder but *not* the folder itself will
> result in an empty folder being copied, which will then be restored as
> empty, but that's not what is normally done and you can't guarantee
> that something not excluded is later added to the folder anyway which
> would be backed up.

What I meant was he was wondering whether restoring would recreate the 
empty cache folders. If the cache folders aren't there, there's no place 
to put new cache files.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#80012

In article <barmar-4BE0C9.22080219092015@88-209-239-213.giganet.hu>,
Barry Margolin <barmar@alum.mit.edu> wrote:

> What I meant was he was wondering whether restoring would recreate the 
> empty cache folders. If the cache folders aren't there, there's no place 
> to put new cache files.

the system install prior to restoring from a time machine backup (which
is required) might create them, but if not, the parent folders can be
created when the cache files are created.

[toc] | [prev] | [next] | [standalone]

#79933

On 2015-09-19, David Empson <dempson@actrix.gen.nz> wrote:
> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>
>> On 15-09-18 18:27, David Empson wrote:
>> 
>> > What on earth gave you that idea? The HFS/HFS+ catalog is a B*-tree.
>> 
>> Sorry my bad. Was thinking about the whole catalogue being a single file
>> and wrongly interpreted this as a flat file.
>> 
>> When you say there are 2 entries for each file, would it be correct to
>> state that one of those is just a pointer to the other ?  (so if you
>> chjange file attributes, only once record needs to be updated).
>
> Yes. I'd have to read the technote again to refresh my memory on how it
> is implemented.

Oh come on, just how lazy a secretary are you, anyway? JF Mezei should
fire you!

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#79938

Jolly Roger <jollyroger@pobox.com> wrote:

> On 2015-09-19, David Empson <dempson@actrix.gen.nz> wrote:
> > JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> >
> >> On 15-09-18 18:27, David Empson wrote:
> >> 
> >> > What on earth gave you that idea? The HFS/HFS+ catalog is a B*-tree.
> >> 
> >> Sorry my bad. Was thinking about the whole catalogue being a single file
> >> and wrongly interpreted this as a flat file.
> >> 
> >> When you say there are 2 entries for each file, would it be correct to
> >> state that one of those is just a pointer to the other ?  (so if you
> >> chjange file attributes, only once record needs to be updated).
> >
> > Yes. I'd have to read the technote again to refresh my memory on how it
> > is implemented.
> 
> Oh come on, just how lazy a secretary are you, anyway? JF Mezei should
> fire you!

In this case, it would at least require a minor degree of research to
find the technote in question, because Apple pulled it from their
developer site. I kept a copy.

For those who are interested in the gory details, you need to find Apple
Technical Note TN1150 "HFS Plus Volume Format".

The last published version (assuming I didn't miss a subsequent update)
was dated "Mar 05, 2004", so it is missing a lot of details about new
features in Leopard and later relating to Time Machine (it also predates
Tiger).

Some aspects require background knowledge of HFS, which was described in
Inside Macintosh: Files (around System 7).

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.mac.system

csiph-web