Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Delete matching files in two Finder folders' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Delete matching files in two Finder folders
Authored by: jacobolus on Sep 13, '05 04:33:34PM

Another good reason why, as John Gruber suggests, replaced files should be moved to the trash, not deleted outright! Definitely a bug if it results in unintentional data loss.



[ Reply to This | # ]
Delete matching files in two Finder folders
Authored by: SeanAhern on Sep 13, '05 07:44:04PM

That might be difficult to implement system-wide. If a (non-Finder) app were operating with a C API, for instance, doing an open(filename, "w") on an existing filename, you would have to capture this at the filesystem level and "Do The Right Thing" (TM), that is, move the file to the appropriate .Trash location. That doesn't exist in any existing filesystem, and you would be hard pressed to do it for legacy filesystems.

Maybe you could write a shim to the "open" system call, but that could cause performance problems and might violate POSIX compliance.



[ Reply to This | # ]
Delete matching files in two Finder folders
Authored by: jacobolus on Sep 14, '05 11:19:32AM

Except that we're talking here about the Finder, not third party apps that are opening files for writing. I'm not suggesting that a unix mv, or a call to write to a file move a file it's replacing to the trash, merely that the Finder do so. Then we could avoid problems such as this one of having the Undo command not actually undo all changes, in the process possibly losing important data.



[ Reply to This | # ]
Delete matching files in two Finder folders
Authored by: sjk on Oct 09, '05 04:43:14PM

I agree with your simple analysis and explanation. Here's looking at the two main perspectives in more detail:

From Finder, crippling Undo context by not restoring files that were replaced by the copy or move is quite arguably a bug because it redefines Undo's anticipated (and intuitively intended, especially for novices) meaning and behavior. However, that does have issues like mmacho mentioned. Anyway, at least for me, Undo usually means "restore everything affected by an action to the state it was in before that action".

From a shell, traditional versions of commands like cp and mv are defined and designed to be irreversibly destructive. There are non-destructive replacements available but unless underlying syscalls are modified (e.g. like SeanAhern's shim) there are too many ways to circumvent non-destructive behavior.

And that leaves us with a mix of what's expected, what's possible, and what actually happens. :-)



[ Reply to This | # ]