Another Finder Data Loss Bug

2018-06-29 • SEND FEEDBACK |
Related: Apple, Apple Core Rot, Apple macOS, macOS Finder

I had just generated 4 images and related posting material in a holding folder.

With another folder active as the top window, I did a Select All, then cmd-delete (which puts selected items into trash) and then cmd-shift-delete to empty the trash. Bingo—all the files in the inactive window below the top one were vaporized. As well, Select All on the still topmost window would not function in spite of it still having all its files. The other folder hidden underneath was now empy bereft of the past half an hour of my work.

This is true data loss that is the fault of Apple bugs. Stuff like this should be fixed before Apple makes one more damned emoji.

I have seen this bug before as well. Beware.

Barton T writes:

I’ve had this problem for ages (on 10.12.6 currently, but also had it in 10.11 and probably further back). Just as worrying I get it reporting the previous size of a folder even when it is clearly empty. So a folder might say it has 86GB but clearly there is nothing in it (or something much smaller). If it’s important stuff that I need to organise I find it safer to check/copy the folder/files in Bridge (that sounds hilarious when said out loud, since Adobe can’t even get Lightroom to remember the last folder exported to properly), or clone folders with CCC.

MPG: yes, it is probably several years old now, stemming from the poor decision to use Spotlight search for inappropriate things, including the speed problems with the Open dialog.

Richard H writes:

Lately we have had huge problems accessing files on our Synology servers. A folder with 18,000 files takes ages to update on the Mac, but if we perform the same operation using Windows in Parallels, it happens in seconds. As you have rightly noted, Apple has lost their way, worrying about new emojis instead of fundamental things like the finder and the file system.

MPG: Recently I used file sharing on a 10.8.5 Mac. Connecting to a server took ~1 second as it always does. On two other Macs running 10.13.5 and for 1-2 years now, it takes ~30 seconds (to the same server and all machines on the same gigabit switch). This can be repeated ad nauseum.

OS update decisions are now the province of 12-year-olds in marketing, from what I can tell.