This is a bit crazy, but since I’m only finding limited discussion of it, and it’s pretty serious, I wonder if it’s happening to more people but they just don’t realize it yet.
A few weeks back Dropbox asked me to update to the latest version, built specifically for Ventura. Apparently Apple added some API and a new location for all your cloud providers to store their files. So after the update, my Dropbox folder had moved from ~/Dropbox to a new location I’d never heard of: ~/Library/CloudStorage/Dropbox.
I only discovered I had problems when I attempted to empty the trash. Somehow my trash folder was actually located in that CloudStorage folder in Dropbox.
I’ve now seen this same thing happen on one of my friend’s macs, too. I specifically checked to see if it was happening. He had no idea anything was wrong.
I assumed the problem was caused by Dropbox, but it seems that the same thing is happening to people with GoogleDrive
I was hoping that 13.1 would fix this, but it didn’t. Is anybody else facing this and does anybody have any tips?
This is a major privacy breach, and I believe it qualifies for a “Bad Apple.”
I don’t use Dropbox or GoogleDrive (so am only guessing) but given this has happened after an update to their apps wouldn’t it seem to be an issue with their apps rather than Apple?
I have iCloud Drive enabled on my iMac and MBP, which keeps the Desktop and Documents folders synched but not the Downloads folder. When I move a file from the Desktop or Documents folder on the iMac, it also appears in the trash on my MBP. However, when I move a file from the Downloads folder on the iMac, it doesn’t appear in the trash on my MBP. It seems that if an item is moved from a iCloud synched folder, it gets moved to an iCloud synched trash folder. If an item is not in a synched folder, it is moved to a local trashcan folder.
If Google Drive and Dropbox behave the same way, I don’t see it as much of a privacy violation as the contents of the file are already on their servers. You’re just moving the file from one shared folder to another. If, on the other hand, you trash a file that’s only on your computer and it ends up on Google Drive or Dropbox, that would be a problem. I’m guessing, however, that is not the way it works because it could cause other problems as well. Unfortunately, I have Google Drive installed on only one computer, so I can’t test that scenario.
Your user’s trash folder is literally moved into the cloud folder. Thus, if you delete something from anywhere on your computer, it ends up in Google Drive or Dropbox.
Hmmm. I must not be understanding this statement, or you’re seeing something I am not. On my MBP (M1 Pro), running 13.1, I have the “standard” Trash folder, located at ~/.Trash. I also have an iCloud Trash folder, located at ~/Library/Mobile Documents/com~apple~CloudDocs/.Trash. These are not the same folder. For one thing, they have different contents, and for another, moving a file into the former does not replicate it in the latter.
Yeah, I’ve not seen this happen with iCloud. But as you can see from the links, and as I’ve described, it’s happening with both Google Drive and Dropbox.
Interesting. Looking at another machine I have that is running Google Drive (Mac Mini M1 running 13.1 and GD 68.0.2.0), I don’t see the issue either. I can drag files big and small into the trash, but there is no sync activity reported in GD. One thing that may be pertinent: on that Mini, there is no folder ~/Library/CloudStorage/, which seems to be the initial path to the problematic .Trash folder as reported in the links you posted. Instead, it appears the local GD folder on this computer is at ~/Google Drive, and there is no .Trash folder in that folder.
I looked a bit deeper on my iMac, and I don’t see what you’re seeing. The local trash isn’t moved to Google Drive or iCloud.
From the reddit threads, it sounds like the bug causes a file from a non-synched location to end up in the Google Drive or Dropbox trash instead of in the local trash folder where it was supposed to go. So it’s not that the local trash folder is moved, but it’s Finder sending the file to the wrong trash folder.
No, if you click the trash can icon in your dock and hit Command-I, it tells you the location of your trash folder. In my case, and in my friend’s case, and in the reddit thread, it is in the Dropbox sync folder in the new CloudStorage folder.
This produces all sorts of strange behavior, including being unable to use the “put back” command on stuff in the trash, as well as being unable to empty the trash, no matter what you do.
Obviously this isn’t a universal bug. You also have to be running the latest version of Dropbox, which not everybody is seeing yet.
I’m really unsure what’s going on here. I was using the beta builds of Dropbox, something I’d turned on months ago to test the new FileProvider approach. When I revealed hidden folders with Command-Shift-period, I could see that both Dropbox and Google Drive had a .Trash folder in their ~/Library/CloudStorage/ locations. Deleting a file or folder with Command-Delete in Dropbox put it into both Dropbox’s .Trash folder and made it appear in the system Trash as well, with a cloud icon.
So all that seems pretty reasonable. What I don’t understand is how your system Trash seems to have somehow become linked with Dropbox. That would imply you could see the full contents of your Trash on dropbox.com and that if you delete a file from a non-Dropbox-managed folder, it’s being sent to a Dropbox-managed Trash folder. Which seems really wrong, as you suggest.
To further confuse matters, I decided to get off the beta builds (build 164.3.7907) to see if I could reproduce what you’re seeing. When I did that, in both Monterey and Ventura, I got version 163.4.5456, which reverted me to the pre-FileProvider approach of just syncing /Users/adam/Dropbox. On both machines, so it’s clearly not required for Ventura.
And worse, while I was writing this, my iMac (Monterey)'s version of Dropbox just updated itself to 164.3.7907 on its own. It still doesn’t seem to be using FileProvider—there’s no Dropbox folder in ~/Library/CloudStorage. Now my M1 MacBook Air has also updated itself to 164.3.7907. So I’m unclear on why they’re both running the same version as the beta they previously used, but now aren’t using FileProvider?
That’s only one of the trash folders. In order to avoid copying files when they are deleted and to prevent one user from seen another’s trashed files, the system maintains a separate set of Trash folders on each mounted volume, including:
~/.Trash. This is the main trash folder in your home directory and will have anything that was originally somewhere under your home directory before it was moved to the trash. (I’m not sure if it will hold files from elsewhere on that volume).
/Volumes/volumename/.Trashes/uid (where volumename is the name of a mounted volume and uid is a numeric user ID). Every external volume should have one of these, if anything on that volume has been trashed by any user. This folder is created for all locally-mounted volumes, regardless of format (I just tested it with HFS+, APFS and FAT).
/System/Volumes/Data/.Trashes/uid. This appears to be a volume-specific Trashes folder for the system Data volume. It’s empty on my system, so it might only be used when the volume is mounted separately from its system volume (e.g. when you’re booted from a different system).
As far as I know, network volumes don’t have .Trashes folders. Files deleted from them are permanently deleted immediately. The Finder should give you a warning about this when deleting these files.
Getting back to the original question, if you have Dropbox configured to backup/mirror your entire home directory (is that an option? I don’t use it), then it stands to reason that ~/.Trash will be backed up along with everything else.
Yep, as I indicated above, this is the one that gets screwed up.
No, that’s not an option.
I’ll report back with the version I’m running now that is fine and the version that is troubling my friend still. (I haven’t had time to figure out how to fix his, yet.)
Can you post a screenshot that indicates this? I tried Get Info on the trash as you suggested, and there’s no indication of where the folder resides on my computers. In one of the reddit threads, someone mentioned doing a Get Info on the items in the trash showed they ended up in the wrong trash can, but that’s different than saying ~/.Trash got moved.
I have no idea how anyone’s Getting Info on the trash as there’s no option for it in the contextual menuy. It can’t be ‘selected’ per se as it just opens the folder and the normal option of Control Clicking the path doesn’t reveal anything.
Getting Info on trashed items is somewhat interesting though given you have both local and cloud items sharing the same Trash can - despite them being in different locations.
I’m going to take this back a few steps, because this discussion has gotten caught up in the question of whether the Trash folder can be relocated at all.
In your original post, you mentioned that:
What, specifically, happened when you tried to empty the trash that indicated there was a problem? I think knowing that may help us figure out what really is going on here.
My version (working properly again, and Dropbox folder in home folder): v164.3.7907
Friend’s version (still broken, and Dropbox folder in new location): v163.4.5456
Good questions on the various trash locations, guys.
Apparently you’ve got to get info on an item in the Trash to see the location, and yes, they can be mixed all together. I think a more accurate way to describe what I’m seeing is that everything is going into a trash folder in CloudStorage, no matter where you’re throwing it away from.
Trying to examine the ~/.Trash folder is quite difficult. In terminal, even
sudo ls -al
doesn’t produce a list of the files in that folder.
However, the point is that hitting Command-I on the items in the trash shows that none of them are in there. Rather, they are all in the CloudStorage location.
So moving things to the trash (in the Finder, at least) doesn’t put them in ~/.Trash, but rather in another trash folder in the cloud. Likewise, I believe that items that were already in ~/.Trash got moved to that cloud folder. (I’m not 100% sure about that, though.) This is basically equivalent behavior-wise to simply moving the ~/.Trash folder to the cloud folder.
ls -la ~/.Trash/
total 63672
drwx------+ 6 pal staff 192 Dec 22 10:12 .
drwxr-xr-x 58 pal staff 1856 Nov 24 13:22 …
-rw-r–r–@ 1 pal staff 40964 Dec 22 10:03 .DS_Store
-rw-r–r–@ 1 pal staff 24573827 Dec 20 10:09 Loopback.zip
-rw-r–r–@ 1 pal. staff 7976962 Dec 22 10:12 silentknight121.zip
That will show you files in the trash only on that volume and trashed only by the user doing the ls. If you have external volumes mounted with stuff in the trash, you’d have to ls the trashes on those volumes, for example:
sudo ls -al /Volumes/external\ drive/.Trashes/501
total 16
...
The unified Trash folder is a Finder construct. It’s gathering files from the /.Trashes/<userid> folders on all (non-network) mounted volumes and from ~/.Trash and presenting them as if they were all in a single folder.
So in the case where ~/.Trash has somehow gotten moved to the cloud, I’d expect ~/.Trash to be empty (or even non-existent), and you’d have to look in the cloud volume’s trash to see its contents in Terminal.
