Author Topic: Git-2d915825cb1d97 - I/O subsystem don't recognized non Latin-1 file name  (Read 429 times)

VictorVG

  • Newbie
  • *
  • Posts: 21
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

  • Moderator
  • Hero Member
  • *****
  • Posts: 2913
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

  • Newbie
  • *
  • Posts: 21
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

  • Moderator
  • Hero Member
  • *****
  • Posts: 2913
I'm very sorry for inconvenience. Please don't hesitate to report issues straight away without prior thorough identification of regression window etc.

VictorVG

  • Newbie
  • *
  • Posts: 21
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. :)
« Last Edit: January 20, 2019, 01:32:13 PM by VictorVG »

eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 2913
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).
« Last Edit: January 20, 2019, 01:37:04 PM by eumagga0x2a »

eumagga0x2a

  • Moderator
  • Hero Member
  • *****
  • Posts: 2913
Can't reproduce with MinGW builds on Windows 7 so far.