http://bugs.winehq.org/show_bug.cgi?id=59905 --- Comment #2 from David <pen.taxi_9u@icloud.com> --- (In reply to Ken Sharp from comment #1)
Please attach the console log, it may offer some clues. https://gitlab.winehq.org/wine/wine/-/wikis/Bugs
The relevant console output is below. When the file is copied in Wine Explorer, Wine advertises CF_HDROP using delayed rendering and maps it to the macOS filename pasteboard type: *** SetClipboardData 000f L"#15" 0000000000000000 NtUserSetClipboardData 000f L"#15" 0x0 set_mac_pasteboard_types_from_win32_clipboard 0x000f L"#15" -> "org.winehq.builtin.hdrop" set_mac_pasteboard_types_from_win32_clipboard 0x000f L"#15" -> "NSFilenamesPboardType" *** The first paste attempt in Finder produces no additional Wine log output and does not paste the file. Pasting once in Safari produces: *** query_pasteboard_data ... type "NSFilenamesPboardType" format_for_type -> ... 0x000f L"#15" NtUserGetClipboardData 000f L"#15" sending WM_RENDERFORMAT SetClipboardData 000f L"#15" 0000000000370108 query_pasteboard_data exporting 0x000f L"#15" export_hdrop_to_filenames export_hdrop_to_filenames L"C:\\users\\REDACTED\\Downloads\\bla.txt" *** After this Safari paste, Finder can paste the file successfully. The successful Finder paste does not add any further Wine log output. This suggests the file list is initially exposed through delayed clipboard rendering. Finder's first paste does not appear to trigger Wine's WM_RENDERFORMAT path, while Safari does. Once Safari causes Wine to materialize and export the CF_HDROP data as NSFilenamesPboardType, Finder can paste the file normally. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.