Hi,
The iPhoto Library is not a single file, its a folder with a hidden extension that lets OSX know to lauch iPhoto should you double click on it. If you right click on it and choose show package contents you will see its just the same as before...
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Why Time Machine is not for me, and maybe not for you either...
- Thread starter neoben
- Start date
- Sort by reaction score
Hi,
The iPhoto Library is not a single file, its a folder with a hidden extension that lets OSX know to lauch iPhoto should you double click on it. If you right click on it and choose show package contents you will see its just the same as before...
5+ Gb fies fore me are video. I'm gonna have those on a second drive anyway. I would have 2 drives the same size and use one for a backup. That would be the best way for large files like that. Pro's aren't gonna put these large files on their main drive backed up by Time Machine anyway. Time Machine is for everyday common type use.
I think the point here is that Time Machine is designed to be a "set it and forget it" backup solution for most users.
Most users don't have a lot of really big files like yours. You seem to be what I would term a "power user" or possibly even closer to "pro user".
It's like iPhoto. iPhoto is a very simple-to-use photo management application. Are there many apps out there with many more features? Yes, but iPhoto is designed to make photo managing easy and fun for regular users.
Most users don't have a lot of really big files like yours. You seem to be what I would term a "power user" or possibly even closer to "pro user".
It's like iPhoto. iPhoto is a very simple-to-use photo management application. Are there many apps out there with many more features? Yes, but iPhoto is designed to make photo managing easy and fun for regular users.
It works exactly as documented. In the case of your mail folder, Apple has changed its own Mail to store everything as individual file, so Microsoft needs to get its own software updated as well.
Wrong. Total size on the disk would be 15MB. It appends the data changes to the files. It doesn't save whole duplicate copies of the same file.
Yes, I think you've hit its purpose on the nose here.
Ahh, the most sought after product for many a stressed college students.Is there any possible way to congfigure Time Machine to grab files from the future? I really need those finished term papers right about now...
So could you explain to me how Time Machine can restore any of the previous versions of a file? I'm not trying to be argumentative; I really want to know how it works. Thanks.
FYI for Aperture users:
http://docs.info.apple.com/article.html?artnum=306853
This is kind of a Time Machine deal-breaker for me. Looks like I'll be sticking with Super Duper until this is sorted out.
http://docs.info.apple.com/article.html?artnum=306853
This is kind of a Time Machine deal-breaker for me. Looks like I'll be sticking with Super Duper until this is sorted out.
Is there any possible way to congfigure Time Machine to grab files from the future? I really need those finished term papers right about now...
We could all use that feature!
Yes, I think you've hit its purpose on the nose here.
Ahh, the most sought after product for many a stressed college students.
So could you explain to me how Time Machine can restore any of the previous versions of a file? I'm not trying to be argumentative; I really want to know how it works. Thanks.
When you launch time machine, what you see is first is the latest version of any file in time machine. So let's say your looking at an application called test.app.
Test.app just came out with an update, so you went ahead and updated it. The total size of the app is now 15mb. It used to be 10 mb yesterday (before the update).
If you go back in Time Machine to yesterday, you can see the old 10mb test.app there.
But if you go to the most recent version of test.app in time machine, what you are actually seing it not just test.app itself, but rather the test.app + whatever has changed. So when you go back, say, a week, what time machine is actually doing is taking away the updated data. Not showing you a previous whole copy.
For those of you who think that Time Machine is saving whole duplicate copies, I really don't know why you would think that. A 100gb drive would be filled in a matter of just a few back ups, which is not the case.
Why do you think that?
Because that's how it works.
On subsequent backups changed files are saved as a whole file.
For more details on exactly how TM works read this: http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/14
Here is the specific part that addresses your question, but I highly recommend reading the detailed description in that link if you want to completely understand how it works. The underlining is mine.
I haven't seen this explained like this anywhere. The only info I've read (namely that Ars Technicia article on the front page) indicates that a new file is created. If you're right about this, it would save people a great deal of grief. However, if you're wrong, it seems that people are going to need larger storage drives for larger files.
Like I wrote before though, if you know that you don't want Time Machine to repeatedly back-up large files, you can exclude them and then back them up manually.
That, by definition, makes it a directory. It may look like a file but it behaves to the operating system like a folder in much the same way that applications look like a single executable but are in fact a bundle (a directory in effect).
Sorry, you are incorrect. Here is a snippet taken directly from Ars Technica:
***
"In this case, the computer name is "Leopard" and the hard drive name is "Leopard Demo." Each "Leopard Demo" folder contains the complete contents of the volume as it existed at the time indicated by the parent folder's name.
Wait a second, the complete contents? Let's see, there are ten date-stamped folders, each containing a "Leopard Demo" folder... does that mean that the Time Machine backup drive shown above is at least ten times larger than the Leopard Demo volume? Fortunately, no. Time Machine is a bit more clever than that.
When creating a new date-stamped backup, Time Machine does not copy any files that have not been modified since the last backup. The same goes for entire folders; if all the files in a particular folder have not been modified, then the entire folder is not copied.
And yet there they all are. If you navigate into one of the "Leopard Demo" folders, you'll see every single file."
Err, you have just agreed with what he said. If you change 1 byte in a 10MB file Time Machine will backup the entire 10MB file again. If the file is not changed Leopard just creates a hard link to the file which accounts for Time Machine showing every single file in every single backup folder.
The quote you just posted clearly states that if a file hasn't changed you'll see it in the folder it's in for each time your mac was backed up, but it's only on the drive once, not once for every time it shows up. So it's more of a UI thing that you see multiples. The actual file has one imprint on the drive.
As already mentioned, iPhoto is not one monolithic file, but a directory with many individual files inside. If you explore the package contents you can still access them with Finder. So, a change made to one photo does not necessitate saving the entire library.
As stated above the iPhoto library is a directory not a file. Plus Time Machine will back up a large file multiple times if it has changed. Thus if you change a 1GB file 4 times you will have 5GBs worth or backups of that file (the original and the 4 changed versions).
Jolton, it looks like you're misunderstanding how it works.
Any file that is changed has another copy of the entire file saved. TM doesn't do a diff and only save the changed data.
In the case of a folder, it only saves changed files, not the whole folder. But if a 10 gig file gets changed, it saves the whole thing again and takes up another 10 gigs.
Hopefully they'll improve it in the future to be able to save partial files, but we're not there yet.
Any file that is changed has another copy of the entire file saved. TM doesn't do a diff and only save the changed data.
In the case of a folder, it only saves changed files, not the whole folder. But if a 10 gig file gets changed, it saves the whole thing again and takes up another 10 gigs.
Hopefully they'll improve it in the future to be able to save partial files, but we're not there yet.
Again, quoted from Ars Technica:
***
Symbolic links and hard links
Mac OS has included the ability to create an "alias" of a file since System 7. Aliases are small, plain files whose contents are interpreted by the Finder and other Mac OS APIs, allowing the original file to be found. To the core OS in Mac OS X, however, aliases are meaningless. They're literally just small, plain files. (In fact, their size is shown as zero because all the data is in the resource fork.) The first part of this lesson is that aliases have absolutely nothing to do with symbolic links and hard links.
For decades, Unix has had two ways to do something similar to what aliases do: symbolic links and hard links. A symbolic link, also called a symlink, is a pointer to another file. The location of this file is specified using an absolute or relative path string. Symbolic links are created with the ln command using the -s flag. Here's an example.
% ls -l
-rw-r--r-- 1 john staff 894 Oct 18 10:04 myfile
% ln -s myfile mysymlink
% ls -l
-rw-r--r-- 1 john staff 894 Oct 18 10:04 myfile
lrwxr-xr-x 1 john staff 6 Oct 18 10:06 mysymlink -> myfile
As indicated by the leading "l" in the Unix permissions string, mysymlink is a symbolic link. It points to myfile, which the ls command shows to the right of the little ASCII arrow. Note that the symbolic link is tiny: only six bytes. That's not a coincidence. Symbolic links are "dumb" in that they literally contain nothing more than the target file path as a string. In this case, the string is the relative path "myfile" which (surprise) is exactly six characters long.
If I move mysymlink to an entirely different directory that also happens to contain a file named myfile, then the symlink will point to that file instead. If I delete myfile, the symlink will remain, still containing that same path string which no longer leads to an actual file. Observe:
% rm myfile
% cat mysymlink
cat: mysymlink: No such file or directory
The error reported is a bit confusing. The mysymlink file still exists. But when the operating system attempts to open that file, it dutifully follows the symbolic link and finds that there is no file at the path specified by the link. The cat command then reports the error it encountered when trying to open the file it was originally told to open.
This property of symlinks can also be considered a feature in some circumstances: "simple" rather than "dumb." But sometimes a more robust mechanism is needed. Enter hard links.
A hard link is simply a reference to some data on disk. Think of a file as a combination of a name and a pointer to some data. Deleting a file really means deleting the name portion of that duo. When there are no more names pointing to a particular piece of data disk, then that disk space can be reused.
Most files have just one name. In effect, every plain file is a hard link. Take another look at the myfile listing from before.
-rw-r--r-- 1 john staff 894 Oct 18 10:04 myfile
See that number "1" right before the word "john"? That indicates that the data linked to the name myfile has only one name. In other words, deleting myfile will drop the count to zero, allowing the disk space previously used by myfile to be used for other purposes. Note that creating a symlink does not increment this number.
% ls -l
-rw-r--r-- 1 john staff 894 Oct 18 10:04 myfile
lrwxr-xr-x 1 john staff 6 Oct 18 10:06 mysymlink -> myfile
In fact, the symlink itself has a "1" in that column, indicating that there is only one name linked to those the six bytes of data. Now let's make a hard link, again using the ln command, but this time with no flags.
% ln myfile myhardlink
% ls -l
-rw-r--r-- 2 john staff 894 Oct 18 10:04 myfile
-rw-r--r-- 2 john staff 894 Oct 18 10:04 myhardlink
lrwxr-xr-x 1 john staff 6 Oct 18 10:06 mysymlink -> myfile
Now the link count for both myfile and myhardlink is two. This indicates that the data linked to by myfile has two names, and the data linked to by myhardlink has two names. In this case, both link to the same data. We have no way of knowing that merely by looking at the link counts; we know because we just ran the ln command ourselves.
Though the size for both myfile and myhardlink is listed as 894 bytes, those 894 bytes exist only once on the disk. Again, it's one chunk of data with two names. As far as the OS is concerned, neither myfile nor myhardlink is the "real" file. They are both equally real, as real as either one would be if the link count was one instead of two.
Since these two files link to the same data, the results of modifying that data will be reflected in each file. For example, let's add five bytes to the chunk of data linked to myfile (the word "test" plus a newline character):
% cat >> myfile
test
^D
Now let's look at the result.
% ls -l
total 24
-rw-r--r-- 2 john staff 899 Oct 18 10:38 myfile
-rw-r--r-- 2 john staff 899 Oct 18 10:38 myhardlink
lrwxr-xr-x 1 john staff 6 Oct 18 10:06 mysymlink -> myfile
The sizes of myfile and myhardlink are now both reported as 899 (894 + 5). Meanwhile, mysymlink is still the lone name linked to its six bytes of data containing the string "myfile".
***
Symbolic links and hard links
Mac OS has included the ability to create an "alias" of a file since System 7. Aliases are small, plain files whose contents are interpreted by the Finder and other Mac OS APIs, allowing the original file to be found. To the core OS in Mac OS X, however, aliases are meaningless. They're literally just small, plain files. (In fact, their size is shown as zero because all the data is in the resource fork.) The first part of this lesson is that aliases have absolutely nothing to do with symbolic links and hard links.
For decades, Unix has had two ways to do something similar to what aliases do: symbolic links and hard links. A symbolic link, also called a symlink, is a pointer to another file. The location of this file is specified using an absolute or relative path string. Symbolic links are created with the ln command using the -s flag. Here's an example.
% ls -l
-rw-r--r-- 1 john staff 894 Oct 18 10:04 myfile
% ln -s myfile mysymlink
% ls -l
-rw-r--r-- 1 john staff 894 Oct 18 10:04 myfile
lrwxr-xr-x 1 john staff 6 Oct 18 10:06 mysymlink -> myfile
As indicated by the leading "l" in the Unix permissions string, mysymlink is a symbolic link. It points to myfile, which the ls command shows to the right of the little ASCII arrow. Note that the symbolic link is tiny: only six bytes. That's not a coincidence. Symbolic links are "dumb" in that they literally contain nothing more than the target file path as a string. In this case, the string is the relative path "myfile" which (surprise) is exactly six characters long.
If I move mysymlink to an entirely different directory that also happens to contain a file named myfile, then the symlink will point to that file instead. If I delete myfile, the symlink will remain, still containing that same path string which no longer leads to an actual file. Observe:
% rm myfile
% cat mysymlink
cat: mysymlink: No such file or directory
The error reported is a bit confusing. The mysymlink file still exists. But when the operating system attempts to open that file, it dutifully follows the symbolic link and finds that there is no file at the path specified by the link. The cat command then reports the error it encountered when trying to open the file it was originally told to open.
This property of symlinks can also be considered a feature in some circumstances: "simple" rather than "dumb." But sometimes a more robust mechanism is needed. Enter hard links.
A hard link is simply a reference to some data on disk. Think of a file as a combination of a name and a pointer to some data. Deleting a file really means deleting the name portion of that duo. When there are no more names pointing to a particular piece of data disk, then that disk space can be reused.
Most files have just one name. In effect, every plain file is a hard link. Take another look at the myfile listing from before.
-rw-r--r-- 1 john staff 894 Oct 18 10:04 myfile
See that number "1" right before the word "john"? That indicates that the data linked to the name myfile has only one name. In other words, deleting myfile will drop the count to zero, allowing the disk space previously used by myfile to be used for other purposes. Note that creating a symlink does not increment this number.
% ls -l
-rw-r--r-- 1 john staff 894 Oct 18 10:04 myfile
lrwxr-xr-x 1 john staff 6 Oct 18 10:06 mysymlink -> myfile
In fact, the symlink itself has a "1" in that column, indicating that there is only one name linked to those the six bytes of data. Now let's make a hard link, again using the ln command, but this time with no flags.
% ln myfile myhardlink
% ls -l
-rw-r--r-- 2 john staff 894 Oct 18 10:04 myfile
-rw-r--r-- 2 john staff 894 Oct 18 10:04 myhardlink
lrwxr-xr-x 1 john staff 6 Oct 18 10:06 mysymlink -> myfile
Now the link count for both myfile and myhardlink is two. This indicates that the data linked to by myfile has two names, and the data linked to by myhardlink has two names. In this case, both link to the same data. We have no way of knowing that merely by looking at the link counts; we know because we just ran the ln command ourselves.
Though the size for both myfile and myhardlink is listed as 894 bytes, those 894 bytes exist only once on the disk. Again, it's one chunk of data with two names. As far as the OS is concerned, neither myfile nor myhardlink is the "real" file. They are both equally real, as real as either one would be if the link count was one instead of two.
Since these two files link to the same data, the results of modifying that data will be reflected in each file. For example, let's add five bytes to the chunk of data linked to myfile (the word "test" plus a newline character):
% cat >> myfile
test
^D
Now let's look at the result.
% ls -l
total 24
-rw-r--r-- 2 john staff 899 Oct 18 10:38 myfile
-rw-r--r-- 2 john staff 899 Oct 18 10:38 myhardlink
lrwxr-xr-x 1 john staff 6 Oct 18 10:06 mysymlink -> myfile
The sizes of myfile and myhardlink are now both reported as 899 (894 + 5). Meanwhile, mysymlink is still the lone name linked to its six bytes of data containing the string "myfile".
Excellent you have just quoted an article that you have completely failed to understand.
What that quote is saying is that when Time Machine backs up your drive if a file has not changed then it will create a hard link to the original thus meaning the file will still show up in the Time Machine UI for that specific update of the backup. If it has changed then Time Machine will backup the entire file again in full.
What that quote is saying is that when Time Machine backs up your drive if a file has not changed then it will create a hard link to the original thus meaning the file will still show up in the Time Machine UI for that specific update of the backup. If it has changed then Time Machine will backup the entire file again in full.