[llvm-dev] TempFile::keep() issue on WIndows

[Adrian McCarthy via llvm-dev]

It's surprising (at least, to me) to get "permission denied" when
attempting GetFilePathNameByHandle.  It seems more likely that the function
failed to resolve the path for some other reason, and then the archiver
tried to do an operation to the file with the unresolved path, and _that_
step caused the "permission denied."

But if it _is_ the GetFilePathNameByHandle, then I would guess that the
file handle is corrupted thus the request is about an object the process
doesn't have rights to access...

I don't have Windows 7 to try it out.

Does the file already exist?  If not, is it being created?  Is there
anything unusual about the path (e.g., is it longer than 256-ish characters
long or referencing a server over a network or contain characters outside
of ASCII that are possibly in the wrong encoding)?

If you're able to debug it at the point of the GetFilePathNameByHandle
call, can you check that the handle looks reasonable?  It should look like
a valid pointer (possibly just the lower 32-bits if you're on a 64-bit
machine), so 0, 0xFFFFFFFF, and unaligned values would be suspicious.

Another common problem is that sometimes anti-malware scanners will briefly
lock a newly created file to scan it, which can cause a sharing violation.
Usually these are intermittent because they're timing sensitive, but it
might be worth temporarily disabling your scanners to see if that makes the
problem go away.  If so, we can look at the access pattern and see if
there's a less fragile approach.

On Thu, Mar 18, 2021 at 4:12 PM Snider, Todd via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi All,
>
>
>
> I’ve run into an issue trying to run an llvm-ar executable built on
> Windows 10 on a Windows 7 machine.
>
>
>
> I get a permission denied error when the archiver tries to write the new
> archive file:
>
>
>
> %> llvm-ar rv mylib.lib foo.o
>
> llvm-ar.exe: warning: creating mylib.lib
>
> llvm-ar.exe: error: mylib.lib: permission denied
>
>
>
> I’ve tracked the issue down to a call to ::GetFinalPathByHandle() from
> realPathFromHandle() (defined in llvm/lib/Support/Windows/Path.inc).
>
> realPathFromHandle() will set an error code when ::GetFinalPathByHandle()
> returns a value of 0 (as it does in the above case).
>
>
>
> Is there a known incompatibility/limitation/bug with trying to run the
> Windows 10 kernel version of GetFinalPathByHandle() on a Windows 7 machine?
>
>
>
> ~ Todd Snider
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210318/4122aa4f/attachment.html>