Desktop 126.11.x (Windows): exports to SMB/NAS shares are saved with the Hidden attribute

Since the Figma desktop app for Windows updated to 126.11.7 (and still on 126.11.8), every file we export directly to our company NAS is saved with the Windows "Hidden" attribute set. Other team members can't see the exported files unless they turn on "Show hidden items" in Explorer. This affects multiple users on our team and started with the 126.11.x update.

Environment

• Figma Desktop for Windows 126.11.8 (also seen on 126.11.7)

• Windows 11

• Destination: SMB network share on a Samba-based NAS (\NAS\Share...)

Steps to reproduce

1. In the desktop app, select a frame and export it as PNG.

2. In the save dialog, choose a folder on an SMB share hosted by a Samba-based NAS.

3. The export completes without any error.

4. In Explorer, right-click the file > Properties: the "Hidden" attribute is ticked.

   Exporting the same frame to a local drive produces a normal, visible file.

Likely cause

A Process Monitor capture posted in the forum thread about the related Google Drive export bug shows that 126.11.x now writes each export to a temp file named ".figma-export-<uuid>" inside the destination folder and then renames it:

https://forum.figma.com/report-a-problem-6/png-export-fails-on-google-drive-for-desktop-after-updating-to-126-11-7-windows-59714

By default, Samba marks any file whose name starts with a dot as Hidden ("hide dot files = yes"). It also stores DOS attributes on the file ("store dos attributes = yes"), so the Hidden flag is kept after the rename. Other tools that use dot-prefixed temp files have hit the same issue (see Samba bug 14977: https://bugzilla.samba.org/show_bug.cgi?id=14977). Since Samba is the default SMB server on most NAS devices (Synology, QNAP, etc.), this probably affects a lot of teams.

Suggested fixes, any of which would solve it

• Use a temp file name that doesn't start with a dot (e.g. "<name>.png.figma-tmp")

• Clear FILE_ATTRIBUTE_HIDDEN on the final file after the rename

• Go back to the pre-126.11 write method

Current workaround: we export to a local folder and move the files to the NAS manually, which works but slows down the whole team.