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.
This blog post by "The Ginger Beard Man" details a method for automatically removing macOS-specific files, namely "._*" (AppleDouble files) and ".DS_Store" files, from external drives upon ejection. These files are created by macOS for various system-level functions, such as storing metadata and resource forks, but can be a nuisance on other operating systems and clutter shared drives.
The author explains that while manually deleting these files is possible, it becomes tedious and error-prone, especially with frequent use of external drives. Therefore, they present an automated solution using a combination of AppleScript and the built-in eject command-line utility.
The core of the solution revolves around a custom AppleScript that iterates through every mounted volume except the boot volume. For each volume, it checks if it's a local or network volume. If it's a local volume and the volume name doesn't match specific exclusions (in the provided example, "Time Machine" is excluded), the script constructs and executes a dot_clean command. dot_clean is another command-line utility, readily available through package managers like Homebrew, which efficiently removes the unwanted "._*" and ".DS_Store" files. After cleaning, the script proceeds to eject the volume.
To seamlessly integrate this process with the system's eject functionality, the author replaces the default eject command with a shell script wrapper. This wrapper first calls the custom AppleScript to clean and eject the specified volume. This replacement is achieved by placing the wrapper script in a directory that precedes the system's /usr/bin in the user's PATH environment variable. Thus, when the user ejects a drive through Finder or the command line, the wrapper script is executed first, ensuring the cleaning process happens before the actual ejection.
The author provides the complete code for both the AppleScript and the shell script wrapper, along with clear instructions on how to install dot_clean, create the necessary files, make the script executable, and adjust the PATH environment variable. They also emphasize the importance of understanding the implications of modifying the PATH and offer advice on reverting the changes if needed. Finally, they mention the option of adapting the script for specific needs, such as excluding different volumes or using alternative cleaning methods.
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.