[Trench]

Thanks all. I've been out of the office the past three weeks, and just now getting back to where I can test this. Note we did also have a Microsoft Patch Tuesday since this was observed, and the machine has automatically restarted to apply those updates since then.

Originally Posted by 44vince44

@Trench, is it possible to edit the properties of your C:\Files\Staxrip\ folder and set permissions (full control) to you as user? do mount points allow that ?

Agreed it's wise to check the permissions, given the evidence.

Although the point still remains that with the tools included and/or invoked by Staxrip 2.1.3.0.Stable or 2.1.4.8.Beta against the same source files in the same folder with the same set permissions, the temp area created by Staxrip could be written to successfully.

And also that using "Run as Administrator", for which those default permissions you're referring to grant Full Control to the Administrators group, hadn't avoided the issue either.

Originally Posted by stax76

The only relevant change I remember is changing the current directory of the staxrip process to the video temp folder, this was not long ago. Before the current folder of the staxrip process was usually the startup folder where staxrip is located. That's something a child process inherits.

Interesting observation that I will keep in mind while continuing to investigate. As you might have noted from the log, the Staxrip program directory in my case is actually outside of the mount point area; in "C:\Users\Trench\StaxRip-x64-2.1.7.0-Stable" instead of "C:\Files\Staxrip". So that kind of current process directory change does seem reasonable to consider.


But today -- as I test this issue which duplicated 100% for files inside of "C:\Files\Staxrip", and for which I had to work around the problem by moving my source files outside of the mount point area -- today the problem no longer occurs.

Since I've been away and not changing anything about the test or the configuration, for the moment I'm assuming Microsoft's Patch Tuesday corrected something here; whether it was also related to process' current directory or not. The patch that applied in my absence was https://support.microsoft.com/help/4598242/, but I do not see any changes with obvious correlation attributed there, other than "unspecified security updates."

Therefore the problem no longer exists at the moment. But should this symptom return, I can pick up with the recommended tests and report back.