J.G.Roeder

Well once again I've taken forever to reply, so long a new version released. I have tried the test per your original instructions using beta 1.10.0115 as a separate install and unfortunately the problem persists. as an addendum I have now also tried using current version 1.10.1.1142 and the problem is present there as well. No additional information to report as behavior and error messages were identical.

Yes I do get the same problem running as Administrator. I had previously attempted this but apparently forgot to include it in my original post. The settings on the Security tab are actually what I was referencing with the word "permissions". They are unfortunately identical for all user groups/names, so this does not appear to be the issue. Was a good thought though.

Ah yeah, I assumed this was the case but there is always the possibility you had some specific information I did not. Any value above zero in windows settings is just "n minutes". Actually the Mac terminal utility for power management "pmset" also uses this convention. With the command pmset -a disksleep 0 Setting disks to never spin down for "all" profiles ( as noted by the -a flag). I really appreciate you taking the time to make a suggestion and even follow up with an explanation.

Thank you for the idea. While my strong preference would be for this to remain at 20 minutes where I had initially set it. The reason for testing it with 0 (zero) is that zero is the equivalent of "never" for this particular setting. So if the turning off of the hard disk was somehow causing this issue, the setting 0 (zero) should mitigate it completely. If there is a specific reason you believe 40 or 60 minutes would help, please elaborate, because it's not immediately obvious to me. Thanks again!

Dan C, Thank you so much for the reply. I apologize for my delay as well, I simply neglected checking in as frequently after some time had elapsed. CHKDSK passed without identifying any issues. As for the the Power Saving plan settings related to Hard disk. I am on desktop so battery wasn't applicable. "Turn off hard disk after" was set to 20 minutes. I updated this to 0 minutes, but experience no difference in the behavior exhibited by Affinity. Thanks again for your assitance!

I am experiencing an issue where I am unable to save new files to a specific drive on my system. This issue did not arise with 1.9.1 and was definitely present in 1.9.0. I'm unsure exactly when it started but it persists in 1.9.1 so I figured this was appropriate. Whenever I attempt to save a new file it results in the "Failed to save document: <Untitled>" "Save failed because access to the file was lost" dialogue. A file is subsequently created on the drive, but with size 0kb. I did find similar issues reported in the forum, but these all seemed to deal with external storage or network drives. In this case, the hard drive in question is neither. It is a standard internal hard drive Seagate ST250DM000-1BD141. Saving to any of the other five drives installed in my system ( one of which is an identical model ) works perfectly fine. I am able to open files which already exist on the drive in question. I am able to save to another drive, move the file to the offending drive, and subsequent saving works as expected. Only new files saved directly cause this issue. The issue is of course infinitely replicable as it happens even with a fresh install of Affinity Designer. I have attempted a full reinstall. Wiping preferences followed by a full reinstall. I've checked permissions to the drive in question multiple times. I monitored the windows event log for any hints. I attempted disabling all anti-virus software. I tried disabling my font manager. I even disabled google drive sync ( which I am not trying to save to ) just in case it was somehow interfering. It's possible, even likely, the issue is still unique to my system but I've run out of leads to chase. OS: Microsoft Windows 10 Pro N Version: 10.0.019041 Build 19041 Affinity Version: 1.9.1.979