Regression: Airdrop Obliterates Declined Files of the Same Name
Originator: | brunerd | ||
Number: | rdar://FB16484921 | Date Originated: | 2025-02-11 |
Status: | Closed | Resolved: | Yes (15.4) |
Product: | AirDrop | Product Version: | 15.3.1 |
Classification: | Incorrect/Unexpected Behavior | Reproducible: | Always |
Description: Airdrop Obliterates Declined Files of the Same Name Steps to Reproduce: 1. Create a TextEdit document named IMPORTANT.rtf and save to ~/Downloads 2. On another Mac create another IMPORTANT.rtf document you could save this anywhere. 3. Initiate an AirDrop from the Mac with IMPORTANT.rtf saved anywhere to the Mac with ~/Downloads/IMPORTANT.rtf 4. Either: A) Decline the transfer on the recipient Mac B) Cancel the Transfer on the sending Mac Expected Results The file is not received and ~/Downloads/IMPORTANT.rtf remains (this is what happens on Ventura) Actual Results ~/Downloads/IMPORTANT.rtf is obliterated on the “receiving”/target Mac, whether the Airdrop is declined locally or cancelled remotely it will destroy the file and it will not be in the Trash (Bin) either Regression Tested on macOS 13 and this does not occur. It is Sonoma (14) and Sequoia (15) only Workarounds Further testing finds if the file name has spaces it is immune from being deleted if an AirDrop of the same name is declined.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at feedbackassistant.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!