This blog post details how to automatically remove macOS-specific files (.DS_Store and ._*) from external drives upon ejection. The author uses a combination of AppleScript and a LaunchAgent to trigger a cleanup script whenever a volume is ejected. The script leverages dot_clean to efficiently delete these often-annoying hidden files, preventing their proliferation on non-macOS systems. This automated approach replaces the need for manual cleanup and ensures a cleaner experience when sharing drives between different operating systems.
The Mac Mini G4 strikes a sweet spot for classic Mac gaming, balancing performance, affordability, and size. Its PowerPC G4 processor handles early 2000s Mac OS X games well, including some Classic environment titles. While not as powerful as the Power Mac G5, its smaller footprint and lower cost make it more practical. The option for an internal optical drive is beneficial for playing original game discs, and it supports various controllers. Though not perfect due to limitations with certain later-era games and the eventual demise of Rosetta, the Mini G4 remains an excellent entry point for exploring the older Macintosh gaming library.
Hacker News users generally agree with the article's premise that the Mac Mini G4 is a good choice for classic Mac gaming. Several commenters praise its relatively compact size, affordability, and ability to run OS 9 and early OS X, covering a wide range of game titles. Some highlight the ease of upgrading the RAM and hard drive. However, some dissent arises regarding its gaming capabilities compared to earlier PowerPC Macs like the G3 or G4 towers, suggesting they offer superior performance for certain games. Others point to the lack of AGP graphics as a limitation for some titles. The discussion also touches on alternative emulation methods using SheepShaver or Basilisk II, though many prefer the native experience offered by the Mini. Several commenters also share personal anecdotes about their experiences with the Mac Mini G4 and other retro Macs.
Summary of Comments ( 18 )
https://news.ycombinator.com/item?id=42987848
Commenters on Hacker News largely appreciated the simplicity and directness of the provided AppleScript solution for removing macOS-specific files from external drives upon ejection. Some highlighted the potential for data loss if used carelessly, especially with networked drives or if the script were modified to delete different files. Others offered alternative solutions, including using
dot_clean, incorporating the script into a Hazel rule, or employing a shell script withfind. The discussion also touched upon the annoyance factor of these files on other operating systems and the historical reasons for their existence, with some suggesting that their prevalence has diminished. A few commenters mentioned more robust solutions for syncing and backing up, which would obviate the need for such a script altogether.The Hacker News post "Automating the cleaning of macOS-specific ( ._ and .DS_Store) files on Eject" generated several comments discussing the author's approach and alternative solutions for managing macOS-specific files on external drives.
One commenter questioned the necessity of the script, pointing out that
.DS_Storefiles are generally hidden and don't cause issues for most users. They also mentioned that these files serve a purpose for macOS systems and deleting them might have unintended consequences. This commenter suggested educating Windows users about hiding system files instead of automatically deleting them.Another commenter highlighted the potential for data loss if the script were to malfunction, emphasizing the importance of robust error handling and thorough testing, particularly when dealing with file system operations. They proposed a more cautious approach involving moving the files to a temporary trash directory instead of immediately deleting them.
Building on this cautionary theme, another user recounted a personal experience of data loss due to a similar automated cleanup script, reinforcing the risks associated with such solutions.
One commenter offered an alternative using
dotfiles, a common way to manage system configurations, suggesting that the script could be integrated into a user's dotfiles repository for better version control and portability.Another user suggested a different technical approach, recommending the use of a shell script triggered by the
ejectcommand itself, rather than relying on external tools or applications. They outlined a basic shell command structure for accomplishing this.Some users discussed the broader issue of cross-platform file management and the challenges posed by operating system-specific files. One commenter noted that similar issues arise with Windows-specific files like
Thumbs.dband advocated for greater awareness and tolerance of these files across different operating systems.Finally, several comments focused on the technical details of the script itself, discussing the use of specific commands and suggesting improvements to its logic and error handling. One user questioned the efficiency of the script's find command and suggested an alternative approach using
locate. Another user pointed out a potential bug in the script's handling of spaces in filenames.In summary, the comments section offered a mix of perspectives, including questioning the need for the script, expressing concerns about data loss, suggesting alternative solutions, and delving into the technical specifics of the script's implementation. The comments highlighted the complexities and potential pitfalls of automated file system manipulation and emphasized the importance of caution and thorough testing.