MacOS – Folder name in sidebar is changed, how to get it back

Before anything, you should try renaming the folder. It will most likely not break your app because of how HFS works. But there are indeed some applications that might not link properly to files.

I could come up with 4 different solutions:

1. This may be the simplest: do it the other way around. Use whatever name you like on the folder and add an Alias to it. Grab the folder with the name you want and add it to the sidebar. The alias will not change. In your instance, you'd rename your Applications from within your "username" folder to something like My Applications and as we already know, that would be the enforced name on the sidebar. Then add an alias (or a symlink) to it called Applications, which will probably work for your program.

   As Daniel said as a comment, you can aditionally hide the alias or the folder (but not the symlink) from finder by using: chflags hidden folder/alias. Use chflags nohidden folder/alias to show it again and with ls -lO (that's a capital o) you can see its flags on Terminal.

2. Use a savedSearch. You can name them whatever you want. Steps:

   1. go to that alternate Applications folder
   2. begin a search typing anything
   3. clear whatever you typed in
   4. select "File Name" (rather than "Contents") and your folder (rather than "This Mac")
   5. press the + sign
   6. press on Kind to add Other
   7. choose File Visibility and suit your taste
   8. press "Save", choose any name leaving the ".savedSearch" intact
   9. make sure "Add to Sidebar" is ticked.

3. If you prefer trying the hack, good luck with it. Basically you would edit ~/Library/Preferences/com.apple.sidebarlists.plist (use Property List Editor if you have XCode installed) and change the Name of your custom useritems and restart Finder. Supposedly option+right click on Finder and Relaunch would do this last trick. I couldn't myself reproduce this and make it work, but maybe it will if you reboot the machine. I doubt anyone would ever build any tweaker for such an overlooked feature.

4. ForkLift is a great Finder alternative that will accept aliases on the sidebar.

The issue here is that Finder implements special handling of files restored from Time Machine to preserve all their permissions, which failed for files owned by the current user's account, but not a group he's a member of.

Usually, when copying files using cp, their attributes aren't retained. This can be changed using the -p option.

-p Cause cp to preserve the following attributes of each source file in the copy: modification time, access time, file flags, file mode, user ID, and group ID, as allowed by permissions. Access Control Lists (ACLs) and Extended Attributes (EAs), including resource forks, will also be preserved.

In both cases, you either copy all or none or these metadata. cp is clever enough to restore them only after all contained files have been processed ([source, see near If -p is in effect, set all the attributes).

If you don't have root permissions, ownership is not retained. The reason for this is that only root can make files owned by users not him and by groups he's not a member of.

To make Time Machine backups viewable but otherwise immutable in Finder, they are protected by Access Control Lists denying all users all modification permissions.

0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown

Since other attributes (other ACLs, extended attributes, file dates and permissions) should be retained when restoring from backup, special handling of these folders is required in Finder. It must remove a specific ACL entry, but retain everything else.

Additionally, Apple apparently wants Finder to retain all ownership information when copying files and directories from backup. This includes the group membership.

If your account is not the owner of the directories in question, Finder requests an administrator password and hands the copying off to its elevated privileges helper program Locum. This does not happen when you are the owner of a file in the backup set.

Now, one of the following cases happens:

• You are not the owner of the file: Finder asks for your password, Locum restores all permissions just as in the backup.
• You are the owner and a member of the file's group: Finder copies the file over and restores the group.
• You are the owner but not a member of the file's group: Finder copies the file over and fails to restore its group.

It's like it's trying to chown username:groupname the file, and prints an error if it fails — which it does if you're neither root (sudo) nor username and a member of groupname.

It behaves slightly differently if you're not copying folders, but files: While file ownership is retained, group membership is discarded if you're not a member of the group. This is what you saw when only copying a single file.

The obvious solutions to this problem:

• Prevent file ownerships that cause restoration to fail (i.e. owned by you and a group you're not a member of — most of the time, this isn't useful anyway)
• Make yourself a member of that particular group at least temporarily. Unfortunately I wasn't able to do this using dscl from the command line in a way that had an effect without logout or restart. Another side effect is that with wheel, you might run into problems with permissions depending on your system configuration.