Handling of UTF8 command argument files regressed in v26.1 breaking Grpc.Tools #17036
Comments
|
Thank you for the bug report. Do you have any suggestions on how to fix it? It sounds like #14197 was supposed to fix this problem, so that is surprising if it actually is the root cause of the problem. |
acozzette
added
protoc
and removed
untriaged
|
It isn't clear what issue #14197 is fixing at all. Grpc.Tools V2.62.0 works perfectly for us when path contains non-ascii symbols, while V2.63.0 breaks. Maybe just |
|
Without trying to reproduce or examine the original issue that #14197 is trying to fix I'm not sure why this fix was needed. The original code treated arguments on Windows (both command line and those read from a file) as just a string of UTF-8 bytes and thus no wchar needed for non-ascii characters. The original problem may just have been environmental - not using the correct Windows codepage when running the command (UTF-8 is codepage 65001). My suggestion would be to revert the fix and then re-investigate the original issue. |
|
I wish my parents naming me, could have been simple. But they ended up with "Joshua Jesper Krægpøth Ryder". This has fucked me several times. Just came back from vacation to find out my Dotnet work projects with GRPC / Proto files no longer build: C:\Users\JoshuaJesperKrægpøth.nuget\packages\grpc.tools\2.64.0\tools\windows_x64\protoc.exe --csharp_out=obj\Debug\net8.0 --proto_path=C:\Users\JoshuaJesperKrægpøth.nuget\packages\grpc.tools\2.64.0\build\native\include --proto_path=Protos --dependency_out=obj\Debug\net8.0\12fbc7ffe642ca7e_common.protodep --error_format=msvs Protos/common.proto Here's the kicker. I don't get to pick my windows name, since it's a work laptop and is predefined from sysadmins..... I am so happy they chose to pick Krægpøth instead of Ryder..... Long rant aside, is there a estimate when this will be fixed ? :D |
We have received several reports in #17036 that the addition of this flag actually broke the use of command argument files with non-ASCII characters in their names. It looks like #14253 ended up fixing the original issue with a different solution anyway. Hopefully this change fixes the issue with non-ASCII characters. PiperOrigin-RevId: 655201610
We have received several reports in #17036 that the addition of this flag actually broke the use of command argument files with non-ASCII characters in their names. It looks like #14253 ended up fixing the original issue with a different solution anyway. Hopefully this change fixes the issue with non-ASCII characters. PiperOrigin-RevId: 655201610
We have received several reports in #17036 that the addition of this flag actually broke the use of command argument files with non-ASCII characters in their names. It looks like #14253 ended up fixing the original issue with a different solution anyway. Hopefully this change fixes the issue with non-ASCII characters. PiperOrigin-RevId: 655660885
|
This should hopefully be fixed now with #17581. |
We have received several reports in #17036 that the addition of this flag actually broke the use of command argument files with non-ASCII characters in their names. It looks like #14253 ended up fixing the original issue with a different solution anyway. Hopefully this change fixes the issue with non-ASCII characters. PiperOrigin-RevId: 655660885
We have received several reports in #17036 that the addition of this flag actually broke the use of command argument files with non-ASCII characters in their names. It looks like #14253 ended up fixing the original issue with a different solution anyway. Hopefully this change fixes the issue with non-ASCII characters. PiperOrigin-RevId: 655660885
|
@acozzette Can we reopen this please. #17581 didn't fix the issue. |
This relates to: Issues: - #17036 - grpc/grpc#36518 PRs: - #15519 The fix in #15519 has one line missing that breaks `Grpc.Tools` and doesn't actually fix the problem it proports to fix. This PR fixes this. This fix needs to also be applied to the version of protobuf that is used by gRPC. There are various scenarios that need to be tested on Windows: **A. Non-ascii command line arguments, e.g.** ``` protoc.exe --csharp_out=out --proto_path=E:\work\grpc\protoctest\test-Dré E:\work\grpc\protoctest\test-Dré\helloworld.proto ``` Failed output: ``` E:\work\grpc\protoctest\test-DrΘ: warning: directory does not exist. Could not make proto path relative: E:\work\grpc\protoctest\test-DrΘ\helloworld.proto: No such file or directory ``` Success output: - no errors printed - generated `.cs` file in the `out` directory **B. Non-ascii arguments in a file containing the protoc arguments (no path to file) e.g.:** ``` protoc.exe @test.rsp ``` where `test.rsp` contains: ``` --plugin=protoc-gen-grpc=E:\work\grpc\protoctest\tools\grpc_csharp_plugin.exe --csharp_out=E:\work\grpc\protoctest\test-Dré\out --grpc_out=E:\work\grpc\protoctest\test-Dré\out --proto_path=E:\work\grpc\protoctest\test-Dré helloworld.proto ``` Success output for both old and fixed code: - no errors printed - generated `.cs` file in the `out` directory **C. Non-ascii arguments in a file containing the protoc arguments (with non-ascii path to file).** (This is what `Grpc.Tools` uses.) e.g. ``` protoc.exe @e:\work\grpc\protoctest\test-Dré\test.rsp ``` Failed output: ``` Failed to open argument file: E:\work\grpc\protoctest\test-DrΘ\test.rsp ``` Success output: - no errors printed - generated `.cs` file in the `out` directory Closes #17854 COPYBARA_INTEGRATE_REVIEW=#17854 from tonydnewell:windows-utf8-command-fix de9ec54 PiperOrigin-RevId: 669083804
What version of protobuf and what language are you using?
Version: v26.1
Language: C# (but any will see problem)
What operating system (Linux, Windows, ...) and version?
Windows - any version
What did you do?
This is causing the
Grpc.Toolsissue grpc/grpc#36518Grpc.Toolsis broken by the protocol buffers change.Handling of non-ASCII characters in UTF-8 command line argument files is broken. It was working in v25.1 and is not working in V26.1. I suspect the cause of the issue to be the "fix" in #14197
Grpc.ToolsV2.62.0 ships with protoc version 25.1Grpc.ToolsV2.63.0 ships with protoc version 26.1Steps to reproduce:
@file)Example of
@file - test.rpsWhat did you expect to see
No errors
What did you see instead?
** Results with older version (working):**
The text was updated successfully, but these errors were encountered: