[Bug 50035] Bugs in ntdll-Junction_Points staging patchset

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50035

--- Comment #4 from Martin Storsjö <martin at martin.st> ---
(In reply to Erich E. Hoover from comment #3)
> (In reply to Martin Storsjö from comment #0)
> > Created attachment 68475 [details]
> > First patch
> 
> This used to be part of:
> ntdll-Junction_Points/0019-kernel32-Implement-CreateSymbolicLink-A-W-with-
> ntdll.patch

Yeah, it seems to have been lost here:
https://github.com/wine-staging/wine-staging/commit/4ffe305c90f9e15141f2c1b10e86a15a5b9b7e3f

> Must have gotten lost in a rebase.  You are missing a free:
>     HeapFree( GetProcessHeap(), 0, linkW );
> that should occur both at the end and if linkW gets allocated and targetW
> fails.

No, I'm taking a shortcut, by passing FALSE to the alloc parameter to the
FILE_name_AtoW function - just like CopyFileA does:
https://source.winehq.org/git/wine.git/blob/f6a5a3d03c1eb914444af96352ca54eec79d7e2c:/dlls/kernel32/path.c#l100

The comment above FILE_name_AtoW says:

https://source.winehq.org/git/wine.git/blob/f6a5a3d03c1eb914444af96352ca54eec79d7e2c:/dlls/kernel32/file.c#l93

 * If alloc is FALSE uses the TEB static buffer, so it can only be used when
 * there is no possibility for the function to do that twice, taking into
 * account any called function.

AFAIK that should be ok here?

> > Attaching two patches that can be squashed into the existing patches in
> > ntdll-Junction_Points. The bugs are that FindNextFileW doesn't properly set
> > the dwReserved0 field (containing the ReparseTag value) if iterating over
> > files in a directory other than the current one, and that
> > CreateSymbolicLinkA is unimplemented.
> 
> That is a good find, I only tested this in wcmd - so I never noticed. 
> Please use sizeof(WCHAR)*2 instead of 4.

Sure

> Also, is there a reason you are avoiding lstrcpyW and lstrcatW?

No, I just wasn't aware of them.

But I actually need lstrcpynW, because info->path points to the full string
ending with "dirname\*", while we just want the dirname. But the intermediate
extra backslash isn't needed as it's included in info->path.Length.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.