gn gen failure on Windows

[Wyatt Hepler]

Hello,

I am running into problems with GN on Windows for Pigweed. I get an error about a file created with generate_file being used by another process during gn gen.

Here's the summarized error message:

$ gn gen 'C:\<build_dir>' --color=always --check --fail-on-unused-args [9200:0426/144652.603:ERROR:file_writer.cc(40)] CreateFile failed for path C:/<build_dir>/<toolchain>/gen/<file_path> The process cannot access the file because it is being used by another process. (0x20) ERROR Unable to write file. I was writing "C:/<build_dir>/<toolchain>/gen/<file_path>".

(example build failure here, though you may not have access)

These errors started occurring when I switched some generate_file commands from the default toolchain to a non-default toolchain (CL). They only occur on Windows for one internal project, and happen about half of the time. They never happen if the generate_file commands are in the default toolchain.

A second, possibly related issue occurs after gn gen succeeds. The directory for an output from an action_foreach does not exist when it runs on Windows, but only for this one project. The directory does exist on Linux or Mac. That is easy to work around -- I just create the parent directory of the output file before creating it (perhaps we should be doing that anyway). Just odd that this only occurs for one project's build on one platform.

Has anyone seen issues like these on Windows?

Thanks,

Wyatt

[Brett Wilson]

I have not seen this. The main Windows GN user is Chromium and it doesn't look like they use the generate_file target type.

Normally for this type of error I would suspect virus checking. I see that this uses WriteFileIfChanged() which will open the file, read it in, and compare the contents. This is important so the timestamps are only updated for new contents which prevents rebuilds. What I've heard happen in other cases is that the first open triggers a virus scan which starts and the rapid close + reopen is fast enough that the virus checker still has the file open. Something similar might also happen for local syncing programs like Dropbox.

Maybe see if you can exclude the directories from scanning?

Brett

[Wyatt Hepler]

Virus scanning could be the culprit. We're running this in LUCI, and I'm not sure what that environment looks like. +Rob Mohr, do you happen to know if there is virus checking that could be running on our repo in LUCI?

The odd thing is that this error always happens with the exact same generated file. I've never seen it with other files. I would expect something like virus checking or syncing programs to cause failures randomly for different files.

We can workaround this for now. Hopefully this issue will remain isolated to this one project.

Thanks,

Wyatt

[ang zh]

I have also encountered this issue, and I know the reason: the file path exceeds the maximum limit of 260 characters (Windows max limit).

 I don't know how to solve it? Modifying the registry doesn't seem to work.

[Nico Weber]

The pragmatic thing is to put your checkout at a fairly short path (`c:\src\myproject`).

You can try to add long path support to all tools you depend on, but that'll be a lot of work in my experience.