Git-2d915825cb1d97 - I/O subsystem don't recognized non Latin-1 file name

[VictorVG]

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.

[eumagga0x2a]

Thank you, the major breakage was reported yesterday and should be fixed by now (last bits not yet pushed). Future nightlies should be OK.

[VictorVG]

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.

[eumagga0x2a]

I'm very sorry for inconvenience. Please don't hesitate to report issues straight away without prior thorough identification of regression window etc.

[VictorVG]

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.

[eumagga0x2a]

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).

[eumagga0x2a]

Can't reproduce with MinGW builds on Windows 7 so far.