Nightly builds after Git-2d915825cb1d97 - don't recognized non Latin-1 file name. File can't be open and if write the disk we see the obvious garbage file name. If create hardlink for this file open success, else if simlink - failre. Example Corrilic file name can't open, then write the disk have the obvious garbage, but if make hard link - all operation is success.
Thank you, the major breakage was reported (https://avidemux.org/smif/index.php/topic,18574.0.html) yesterday and should be fixed by now (last bits not yet pushed). Future nightlies should be OK.
Big thanks! I have this bug after this commit, but after this commit, and for several days I dealt with its nature (at the same time and in my code, order brought: - there it was necessary to refactor a number of scripts to start, but there was no time). This is where Process Hacker got me and rescued - once there are no headers on the file, then the I / O operation failed. Then only search for a place where an error could occur.
I'm very sorry for inconvenience. Please don't hesitate to report issues straight away without prior thorough identification of regression window etc.
Ok! Now I'm trying to figure out what's going on in Process Hacker - some versions crash with Access Violation (AV) when it starts up for the first time after assembly and attempts to send a failed process to the debugger or to get minidumps are useless. Clicking the minidump button in the crash window causes a new AV and creating a zero-size dump file :), and the debugger says that the problematic process has already ended with return code 0. :( I am inventing a way to check for suspicion of an error in the Updater plugin - it looks like it incorrectly interprets time The last check. Fun entertainment, especially considering that recently we have been messing with him because of this AV. :)
Do you refer to the win32 build (legacy-compat branch, MinGW), the win64 build (ffmpeg4x branch, MingGW) or the vsWin64 build (ffmpeg4x branch, VC++)?
Ah, now I got that you meant "after build", not an issue with some assembly (assembler code).
Can't reproduce with MinGW builds on Windows 7 so far.