Save Bug After Storage Disconnection Prevents Saving In-Memory Copy to Local Disk

[Alkani]

Synopsis
When trying to save Designer files to the local disk or a removable disk after an interruption in the removable disk, Designer is unable to save the files citing a lack of permissions to do so.

 

Severity
3 - This issue is troublesome, but has a workaround that doesn't impact operations (individual contributor PC work).

 

Scenario
I keep working files on a local USB-attached external hard disk. However, as of late, the USB device has become unstable (the machine is old and survived a number of brownouts and power spikes). The situation isn't likely to be resolved for some time due to budgetary constraints. When these interruptions occur, Windows immediately detects and reattaches the USB disk drive. However, when trying to save the Designer file, either to the local desktop or to the USB drive after one of these events occurs, Designer is unable to save a file to either of these locations despite their availability in Windows explorer, citing a permissions issue. Since this seems to be an issue with Designer being unable to save a file, even to *local* disk after an interruption, this issue warrants some investigation. While losing connectivity is annoying, it's more annoying that Designer can't save a file *anywhere* when one of these disconnections occurs, despite seeing locations in the file system.

 

Workaround
For the time being, I am saving the working files to the local storage device.

 

Recreating the Issue

1. Attach a USB 3.0 external disk drive to a PC running Windows 10 Professional (10.0.19042 Build 19042) and running the latest version of Affinity Designer (1.9.1.979). Ideally, the disk drive should be an NVMe-based, m.2 SSD, such as a Samsung EVO m.2 mPCIe SSD in an external case (I'm using a Sabrent external case enclosure).

2. Open a new file in Affinity Designer. Get some progress, then save work to the USB 3.0-attached external disk drive, then perform some additional work without saving to disk.

3. Instigate a drive crash in the USB 3.0 driver for the particular system. This may be difficult, but with the appropriate developer tools, a crash can be forced in a driver.

4. Perform driver recovery or allow for Windows to recover the driver gracefully, if possible (this should re-detect the externally-attached disk drive).

5. Attempt to save the file. The file should not save, citing a permissions issue.

NOTE: when trying to simulate a failure by disconnecting the USB 3.0 external drive manually (dirty), I was able to save a file locally and to the removable storage. I believe the key may be in crashing the driver and forcing it to recover using whatever internal process Windows uses. There may be something in the kernel driver recovery process that Affinity Designer doesn't like, which is causing the permissions issue (such as, for example, a file handle reference for a device as presented in the kernel that has changed underneath it that the software doesn't handle well).

 

I don't expect there will be any resolution; this could be a local hardware issue entirely. However, since the problem is "weird" to say the least, I wanted to report it just in case it's a symptom of an underlying bug that wasn't detected during normal release testing, especially considering the permissions issue that arise.

 

Thank you!

 

Edited March 17, 2021 by Alkani

[Sean P]

Hi Alkani,

Thanks for letting us know. I've been trying this using both a VM (with a physical USB device connected) and a physical machine and not able to reproduce this behaviour. However I don't have a way of forcing a driver crash with the USB 3.0 drivers. Is there other ways you would suggest to force this or recommend any tools?

We do test the dirty method you mentioned with just disconnecting it and this does recover as you have also found out.