Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.4: A caution on the functionality of Burn Folders System 10.4
Tiger only hintI have just started using Burn Folders under Mac OS X 10.4. I had previously dismissed them as similar in concept to the old Mac OS 9 style burn folders -- which basically just created a hidden disk image, then burned the disk image to media. IMHO, this was a long way of doing a pretty simple thing. But after reading some comments about Burn Folders and how they used aliases, I thought I would give it a try. So this weekend I started experimenting with Burn Folders, and found them to be quite useful.

Except for one little thing I discovered quite by accident. I had created a Burn Folder and dropped a few other directories into the Burn Folder, which in turn had a few directories inside them. I realized just before I decide to burn the Burn Folder that I really didn't want to burn a few of these sub-directories. So I proceeded to go into the directories in the Burn Folder and delete the items -- thinking I was just deleting aliases to the items (as their parents are). Luckily, I decided to investigate before emptying the trash. Turns out that only the top level directories you drag into the Burn Folder are actually aliases. If you dig into those and start tinkering, you are actually modifying the original files on disk.

Now if you think about it, this is probably the way it should be, and it is the way the rest of the system works with regard to aliases. I was just a little stunned that I was able to so easily delete data without a warning or anything. Maybe Apple should somehow add a trigger mechanism to the Burn Folders that alerts the user that any modifications you make to items inside the main aliases is actually modifying the real data files/directories.

[robg adds: The behavior of Burn Folders can be a bit disconcerting, but it's definitely normal practice for folder aliases in general: once you double-click an alias folder, you switch into the actual directory (since the alias itself is just a pointer to that folder). Relative to Burn Folders, Apple tries to provide some visual guidance to help. When you're in the top-level of a Burn Folder, you'll see this header in the window (in list, icon, or column-view mode):


As soon as you navigate into any folder within the Burn Folder, though, the header will disappear, leaving a normal-looking window. In column view, this is quite obvious, as everything in the window jumps up when the header vanishes. It's not quite so obvious, though, when working with list or icon view, or if you have the Finder open a new window each time you open a folder. You can always check where you are in the directory structure by command-clicking on the title area of the window (this will show a drop-down menu with the full path to your current location).

I'm not sure how Apple could do this much better, as a pop-up warning every time you modified something after visiting a Burn Folder could get quite annoying. But this hint is a good heads-up, especially for those new to Burn Folders, to exercise caution when working with aliases you've placed into said folders.]
    •    
  • Currently 1.71 / 5
  You rated: 1 / 5 (7 votes cast)
 
[18,421 views]  

10.4: A caution on the functionality of Burn Folders | 16 comments | Create New Account
Click here to return to the '10.4: A caution on the functionality of Burn Folders' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.4: A caution on the functionality of Burn Folders
Authored by: sth on Sep 15, '05 10:15:04AM

If you copy your items into the burn-folder (hold the opt-key while dragging), you can delete sub-items safely.



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: dan55304 on Sep 15, '05 12:14:58PM

I don't know how I missed the burn folders feature. Seems ideal for daily backups. I created my burn folder and put my development, documents, and Library->Mail folder in it. Evidently that can't work. I get this error written to the console:

Finder: Warning - generated file '.FBCIndex' has unusual st_mode value (0100606 octal) in HFS+
Finder: Burn failed, Thu Sep 15 11:09:17 2005
Finder: Burn error: -43 0xFFFFFFD5 Could not retrieve information for "<unable to get file path>" (-43).

Is there a way to filter out "system" files? I find it odd that it's even attempting to write them.



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: morespace54 on Sep 15, '05 01:56:23PM

I dont know but it seems that my "burn" folders wont get burned if they exceed 650/700 MB... So what should I do if I want to burn my folder on a DVD?

maybe I'm missing something here...



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: vsopal on Sep 15, '05 02:06:21PM

If you insert DVD it will detect it and allow You to burn all 4.38 GB



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: lar3ry on Sep 15, '05 03:52:24PM

What the original poster thought was happening (and is not really all that difficult to perform, actually) is what is called a "symlink farm."

There's a utility within the X11 build tree called "lndir." What this utility does is create a set of links to all the original files. In order to do this, it copies the directory structure (the directories aren't symbolic links), and then for each file within a given directory within the source tree, a symbolic link is made in the destination tree. (lndir has other options that allow it to exclude certain subdiretories or backup files, but that's not the point here).

The upshot is that it is quite feasible (and easy!) for Apple to implement this sort of functionality.

The BEST solution would be for the Finder to actually identify symlinks. That is, if a directory in a burn folder is actually a symbolic link to another directory, there should be some sort of mask on it... turn the folder green (might be a problem if the user is color blind), or put a tiny arrow on top of it (shades of Windows!)... and do the same sort of thing for files.

That way, people that are perusing a burn folder should be able to tell whether the files or directories that they are looking at are actual files that will disappear if they are deleted or just links to existing files.

(Extra points, Apple: If you adopt the "arrow" mask that Windows uses to denote symlinks, then also add a "broken arrow" mask that denotes broken links... symlinks to files that no longer exist!)



[ Reply to This | # ]
Shadow arrows
Authored by: ktohg on Sep 15, '05 06:09:47PM

They do. all aliases have a nice unobtrusive black arrow in the lower left hand corner denoting an alias.

No broken arrow for broken aliases but finder makes it pretty blatantly clear that the original is not there when you attempt to open the alias.



[ Reply to This | # ]
Shadow arrows
Authored by: eduo on Sep 16, '05 05:25:37AM

You're confusing Aliases with Links.

Aliases are OSX-specific (in the same way 'Shortcuts', or "lnk" files are exclusive of Windows).

Links are Unix-specific and are not the same as aliases. Symbolic links are small files pointing to the real files and the Finder currently doesn't interpret them in any way. When you see a link you see the actual endfile. And it's actually worrying because it applied the permissions of the containing folder, not of the actual end file.

A good example of link (not aliases!) farm is what iPhoto used (dunno if newer versions still do) to do when the same photo was in several albums or in CDs burned from within iPhoto. Photos showed as duplicates but were actually links.

Eduo

---
Eduo



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: kevin_1 on Sep 15, '05 07:35:18PM

i dont use burn folder. i use toast. But apple should definitely get it improve. wtf.



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: arglborps on Sep 15, '05 09:39:47PM

I think it should be pretty obvious that you can't put any files into an alias of a folder, because an alias is a file that simply points to a real folder on your harddisk it cannot have any content by itself.

It's the same with aliases in the Finder. Or did you expect that if you make an alias of a folder, then open the alias an delete some files in there you'd only delete aliases to all the files? No.

THIS IS CONSISTENT BEHAVIOUR.



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: morespace54 on May 09, '07 11:41:12AM

Maybe but you do *select* a folder to make an alias of it while you *create* a burn folder... Just like you would create a fresh new folder in the Finder if you wanted to move your stuff for further backup purpose.



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: starwxrwx on Sep 15, '05 11:31:47PM

I have found Burn folders to be nothing but trouble.

First off, I still have the problem that sometimes dragging multiple files to the burn folder causes all the aliases to point to the SAME file. So I get a cd/dvd of 10 copies of the same file - this has reappeared for me under 10.4.2. (Opt-cmd-I is the only way to ensure the aliases are correct... but sometimes folders original paths dont turn up properly anyway, and checking each alias can get annoying for large backups).

Secondly, if you try to backup your ~/Library, it can crash halfway through the burn if some random folder has a protected/non-copyable file (what is with these files? Everything should be copy-able). hello, coaster land.

Also, trying to backup your Desktop can cause trouble because thats where the default Burn folder is!

I also find the 'calculate burn size' to be really unreliable, and often quotes larger amounts than "get info" on the folder you wish to burn.

Opt-dragging files helps, but is SLOW, and because it's copying, it still fails for certain Library directories, and you have to go hunt them down to check what files you are missing.

Overall, I have to say it just gives me a headache, and I'm an experienced user...



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: sjk on Sep 16, '05 01:23:35AM
Re: it can crash halfway through the burn if some random folder has a protected/non-copyable file (what is with these files? Everything should be copy-able)

Try running:

find ~/Library -not -user yourusername -not -type l -ls

... in a Terminal shell to check for non-symlink files/directories you don't own. For example, you might discover root-owned, read-only-by-owner files under the Preferences directory.

[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: BohrMe on Sep 18, '05 09:37:47AM
Everything should be copy-able.

No it shouldn't. Whether you want it to be or not, OS X is a multi-user operating environment. And because of that, certain security measures have to be taken so that you or another user of the computer won't muck it up or compromise the system's integrity.

One of the ways a UNIX system does that is to make certain files and/or directories rw by root or daemon or some other user whose UID is less than 50, IIRC. That's why you have to enter your administrator password when installing some software.



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: dave1212 on Sep 18, '05 11:47:12AM

I think he was talking about the Home folder. Everything should be copyable/burnable from his own user folder.

Right?

As an aside, the issue could have got me too, as I am used to Toast's behaviour (as I'm sure many Mac users are) of letting you work within the 'burn' window without affecting your actual files. Change names, icons, move to different folders, nothing in the Finder was touched.

This is odd behaviour for something that so many Mac users will expect to act like Toast. Unfortunate, although it shouldn't be any issue for Apple to figure out a fix, they don't worry about their own HIG anymore anyway.



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: legacyb4 on Oct 09, '05 08:52:34PM

I've noticed the same thing.

I had a handful of music files I wanted to back up on an external drive since DVD-R is so much cheaper than hard drive space for archiving.

Dutifully, I created a Burn Folder on the Desktop, dragged the folders from the external drive into the BF, noted that all folders were aliased, and burned it only to find that all folders had the same subfolder (probably the one that was clicked on when dragging the group over).

I tried creating another BF on the external drive and did another drag; same result.

I finally moved the folder full of music files to my Desktop, created a BF on the Desktop, dragged the folders in, and now the links work.

Perhaps there is a bug with external FW drives?



[ Reply to This | # ]
10.4: A caution on the functionality of Burn Folders
Authored by: Anonymous on May 08, '07 06:24:24PM

My how I wished I had read this BEFORE trying to backup my computer... Not an irrecoverable problem but I did succeed in deleted my entire iTunes music folder this way. I wanted to burn a copy of my user data - sans the iTunes Music folder which was too big and needed a second DVD. I copied my home directory to the burn folder and then searched through to find and remove the iTunes Music folder. I didn't look back at this until well after I had emptied my trash, I'm not a frequent iTunes user. LUCKILY I had burned the DVD containing my iTunes Music before burning the remaining user content, I am now restoring from my backup.



[ Reply to This | # ]