Symbolic links and inadvertent file deletion The Finder in Mac OS X 10.3 contains a problem with respect to symbolic links which could lead to inadvertent data loss by users with administrative access. The issue was first reported by MacFixIt reader Erick Wong, and subsequently confirmed in-house.
"The problem appears to lie in the new authentication code in Panther Finder which allows privileged file operations to be carried out with the appropriate password. To reproduce it, use the Terminal command line to first create a folder which owned by root and writable only to root. Then create a symbolic link within that folder, to any file (preferably one that is unimportant).
- % cd ~/Desktop
- % mkdir foodir ; cd foodir
- % touch foo
- % ln -s foo bar
"Now navigate to the newly-created folder from the Finder, and drag the symbolic link (which appears to the Finder as an alias) to the Trash, authenticating as necessary. A moment later, we see that the symbolic link is back to where it started, and the file in the Trash is actually the target of the link."
"The severity of this bug is exacerbated by the fact that many of the symbolic links in an OS X installation exist in privileged directories and link to critical system files. I personally discovered the problem while going through the archived system of a machine I recently upgraded to Panther using 'Archive & Install.' In the archived copy of /usr/sbin there is a symbolic link to AppleFileServer in /System/Library/CoreServices.
"Since the symbolic link uses an absolute pathname, the old link actually points to the working executable in Panther. If I had not had the fortune of noticing the strange behavior of the link reappearing after I trashed it, I would never have noticed that AppleFileServer had been moved to the Trash before emptying it!"
In order to reproduce this issue in-house, we had to set the privileges of the folder in question to "Read Only" after making that change, we were successfully able to drag the file "bar" (the symbolic link from the above example) to the Trash, and watch the file "foo" (crated by the command "touch foo") move to the Trash instead.
The symbolic link manual, accessed via the "man ln" command in the Terminal explains:
"By default, ln makes hard links. A hard link to a file is indistinguishable- able from the original directory entry; any changes to a file are effectively independent of the name used to reference the file. Hard links may not normally refer to directories and may not span file systems."
However, the manual for rm (deletion command) states "The rm utility removes symbolic links, not the files referenced by the links," contradicting this confirmed behavior.
Retrospect inconsistently auto-launches Dantz' Retrospect has a fairly serious flaw under Mac OS X 10.3.x that certainly deserves some more attention for those considering purchasing the backup tool.
As noted in the company's support database:
"Retrospect may inconsistently autolaunch. Leaving Retrospect running will allow for script execution.
MacFixIt reader Tom Mulhall writes "This has been a factor since 5.1 and Panther (OS 10.3.x) have been together. It has now been many, many months; and Dantz has not yet come up with a fix for this problem-- it is something that is intolerable. My clients are furious with not being able to get consistant backups, as are we (my personal system didn't run for 9 days, with multiple daily runs programmed!!) We have now had clients lose data due to this bug."
Version 6.0 of Retrospect may fix this issue, but the update will not be released until January 26, 2004, and will not be in the retail channel until February.
Version 5.1 also displays these launch issues under Mac OS X 10.3.x:
- Retrospect is not able to autolaunch at the Panther login screen. Computers left at the login screen can be successfully backed up with the Retrospect client software.
- Retrospect may not launch on the first attempt after logging out or restarting. Trying to launch Retrospect a second time should be successful.