{"id":261,"date":"2003-03-02T23:28:12","date_gmt":"2003-03-03T04:28:12","guid":{"rendered":"\/?p=261"},"modified":"2025-07-03T18:51:36","modified_gmt":"2025-07-03T22:51:36","slug":"finder_filefolder_overwri-2","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2003\/03\/02\/finder_filefolder_overwri-2\/","title":{"rendered":"Finder File\/Folder Overwrite Again"},"content":{"rendered":"

\n\nJohn Gruber<\/a> weighs in on the discussion that I previously mentioned<\/a>. I see where Rentzsch<\/a> and Gruber are coming from, but I’m not convinced. I’d be happier with a well-worded dialog that made cancelling the default option.\n\n<\/p>\n\n\n\n

\n\nIf you invoke Undo, the Finder will move the replacement item back to its previous location, but it will not bring back the item that was deleted<\/em>.\n\n<\/blockquote>\n\n\n\n

\n\nIf there is a bug, it is this. The Finder should not enable its Undo command if it cannot provide a complete undo. Imagine if the replaced item is not in view. After choosing Undo, the user will think that it has been restored. In fact, even if the containing folder is<\/em> in view, the user may simply trust<\/em> that since the Mac didn’t complain the Undo completed successfully.\n\n<\/p>\n\n\n\n

\n\nI believe there is a solution which should make everyone, Rentzsch and Bumgarner alike, very happy: the Finder should move the replaced items to the Trash.<\/em>\n\n<\/blockquote>\n\n\n\n

\n\nSounds like a good idea. It brings back happy memories of Central Point’s TrashBack<\/a>. Of course, the Finder engineers would still have to make a choice in the case where there isn’t enough disk space.\n\n<\/p>\n\n\n\n

\n\nWith my suggestion that replaced items be moved to the Trash instead of deleted, this poses a problem. Aliases pointing to the original item will resolve to point to the original item in the Trash, not the replacement in the original location. If you empty the Trash first, there won’t be a problem, but the whole point of the Trash is that you’re allowed to keep items sitting inside it. I think this might be solvable by adding some smarts to the Alias Manager, such that if an alias’s target is in the Trash and there is a newer item in the original location, it could reassign the alias to the new item. \n\n<\/blockquote>\n\n\n\n

\n\nI’m not an expert on this stuff, but it appears that the Finder could exchange<\/a> the file references so that aliases point to the new item, not the one in the trash. No need for an “if it’s in the trash” hack.\n\n<\/p>\n\n\n\n

\n\nAll this said, I’m not sure I’d like the Undo command to bring the original item out of the trash, because I doubt the Finder can guarantee that the restored item will be identical to the original. Another program could alter it while it was in the trash. This is similar to the problem where the Finder’s Copy command copies a reference to an item, not the item itself, thus breaking<\/a> the clipboard’s standard behavior. Let the user restore the item manually, if desired, but don’t call it Undo.\n\n<\/p>","protected":false},"excerpt":{"rendered":"

John Gruber weighs in on the discussion that I previously mentioned. I see where Rentzsch and Gruber are coming from, but I’m not convinced. I’d be happier with a well-worded dialog that made cancelling the default option. If you invoke Undo, the Finder will move the replacement item back to its previous location, but it […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"2025-07-03T22:51:14Z","apple_news_api_id":"cd1d6371-be1f-464c-8622-87188e36bb2f","apple_news_api_modified_at":"2025-07-03T22:51:38Z","apple_news_api_revision":"AAAAAAAAAAAAAAAAAAAAAA==","apple_news_api_share_url":"https:\/\/apple.news\/AzR1jcb4fRkyGIocYjja7Lw","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[2],"tags":[2786,458],"class_list":["post-261","post","type-post","status-publish","format-standard","hentry","category-technology","tag-aliases","tag-finder"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/261","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=261"}],"version-history":[{"count":1,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/261\/revisions"}],"predecessor-version":[{"id":48330,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/261\/revisions\/48330"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=261"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=261"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=261"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}