Fix regression from #314 (chmod missed fix) #330
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
evilmartians#314 introduced a [regression](evilmartians#314 (comment)) that passes quoted paths to `fs.chmod`. [`fs.Chmod`/`os.chmod` on windows](https://cs.opensource.google/go/go/+/master:src/syscall/syscall_windows.go;l=647;drc=242adb784cd64265ce803f6b0c59dbf126bcda9c) calls into the [`GetFileAttributes`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileattributesw)/[`SetFileAttributes`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileattributesw) win32 api directly. The win32 api expects a "strongly typed" path, without quotes, unlike a command line string, and doesn't try to *parse* it. Passing quoted paths to fs.Chmod causes the operation to fail - valid paths do not begin with quotes! This change moves the path quoting down into `runScript`, so that we can pass the UNquoted path to `fs.Chmod`. To my great surprise, it looks like go does NOT check `GetLastError` when `GetFileAttributes`/`SetFileAttributes` fails? This is disappointing, because somewhere down the stack, procmon says windows returns "NAME INVALID", which is probably `STATUS_OBJECT_NAME_INVALID`. Poking around kernelbase.dll in GHIDRA shows a couple places where it sets last error, and you can see plenty more in the ReactOS sources.
|
Scratch that last bit about GetLastError, I didn't know that go did some inline assembly work behind the scenes to transparently grab it. Nice. Fixing linter warning now. |
mrexox
reviewed
Sep 27, 2022
|
Will make the change. |
Believe it or not, I'm NOT a C89 programmer, I hate code that initializes variables at the top of the block. And yet, here I am. *Something something cobblers kids have no shoes something*
|
Yay! I've been using |
|
May I ask pretty please that you push this to release 😉 I suspect you're busy and it just fell off your radar! |
|
@ariccio , sorry for the long wait. I have just released the fix in v1.1.2. |
|
No need to apologize, much appreciated!! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#314 introduced a regression that passes quoted paths to
fs.chmod.fs.Chmod/os.chmodon windows calls into theGetFileAttributes/SetFileAttributeswin32 api directly. The win32 api expects a "strongly typed" path, without quotes, unlike a command line string, and doesn't try to parse it. Passing quoted paths to fs.Chmod causes the operation to fail - valid paths do not begin with quotes!This change moves the path quoting down into
runScript, so that we can pass the UNquoted path tofs.Chmod.To my great surprise, it looks like go does NOT check
GetLastErrorwhenGetFileAttributes/SetFileAttributesfails? This is disappointing, because somewhere down the stack, procmon says windows returns "NAME INVALID", which is probablySTATUS_OBJECT_NAME_INVALID. Poking around kernelbase.dll in GHIDRA shows a couple places where it sets last error, and you can see plenty more in the ReactOS sources. Guess I'll have to file a bug in go to satisfy my OCD :)