Uh oh!
There was an error while loading. Please reload this page.
fs: fix long symlinks in realpath - #7548
Conversation
There was a problem hiding this comment.
I think having a comment here about why 32 was chosen might be helpful.
There was a problem hiding this comment.
heh. true.
@saghul There a reason you mentioned 32 in your comment?
There was a problem hiding this comment.
oops. missed that. thanks.
Trott
commented
Jul 5, 2016
Possible/reasonable to add one or more tests? |
Trott
commented
Jul 5, 2016
/cc @jhamhader |
trevnorris
commented
Jul 5, 2016
Comment in OP :-)
|
Trott
commented
Jul 5, 2016
Heh...I got as far as "feedback" and stopped. Last mile problems. |
There was a problem hiding this comment.
won't this be a problem on Windows? (I this code ever gets run there, that is)
There was a problem hiding this comment.
I couldn't see in any of the win calls of uv_fs_realpath() that could return ERROR_CANT_RESOLVE_FILENAME (mapped to UV_ELOOP). Specifically those are CreateFileW() and pGetFinalPathNameByHandleW(). I just added a couple tests that will push up in a moment and run CI to check.
There was a problem hiding this comment.
@saghul So, seems I can get ELOOP from windows. Working on that.
trevnorris
commented
Jul 6, 2016
Updated and running CI: https://ci.nodejs.org/job/node-test-commit/3996/ |
trevnorris
commented
Jul 6, 2016
Hm, the PR doesn't build properly on Windows. Looking into it. On all the Not sure why that's failing for Windows and not any other box. From Not sure what that's about. |
Fishrock123
commented
Jul 7, 2016
cc @nodejs/platform-windows ^^^ |
bzoz
commented
Jul 7, 2016
If you change macro call |
bzoz
commented
Jul 7, 2016
It's a thing with how msvc expands #defineEXPAND(X) X
#defineSYNC_CALL_NO_THROW(func, path, ...) \
EXPAND(SYNC_DEST_CALL_NO_THROW(func, path, nullptr, __VA_ARGS__)) |
@bzoz Thanks much for looking into this. Does make me curious why the use of EDIT: Ah yup. I see it now. Thanks for pointing this out. Missed that the macros could be simplified, which will solve the issue. |
trevnorris
commented
Jul 7, 2016
Realized two things. 1) this doesn't address the async call (small oversight...) and 2) it can be made more reliable than it was before. Working on both. |
trevnorris
commented
Jul 7, 2016
Updated w/ most of it, but going to forget the "more reliable" part for now. That's an enhancement for another PR. |
Compiling but now getting an issue with the resolved path on windows. Looking into it. EDIT: Looks like it may be from exceeding |
trevnorris
commented
Jul 7, 2016
Path length fixed. |
There was a problem hiding this comment.
Would it make more sense to do a single async call to ResolveRealPath instead of mirroring the C++ code in JS?
There was a problem hiding this comment.
I agree. Reason I did it this way was because handling/passing the async resources was being a thorn at the time. I'll see about moving this into C++.
@nodejs/platform-windows Nm. Just noticed that it didn't fail b/c the test wasn't actually running... Can repro. |
trevnorris
commented
Jul 8, 2016
Think I got it this time. |
Fishrock123
commented
Jul 11, 2016
@trevnorris Lots of failures. :/ |
trevnorris
commented
Jul 11, 2016
@Fishrock123 Yeah. But Windows passed! Not sure if that's progress though... |
trevnorris
commented
Jul 11, 2016
Another CI to help me understand what's going on: https://ci.nodejs.org/job/node-test-pull-request/3248/ |
trevnorris
commented
Jul 11, 2016
@addaleax Heh. I'm somewhere between JS and C++ here. Thanks for the reminder what I'm actually coding. |
trevnorris
commented
Jul 11, 2016
Here we go again. CI: https://ci.nodejs.org/job/node-test-pull-request/3250/ |
addaleax
commented
Jul 11, 2016
Btw… is there any reason for the path delimiter to be on |
trevnorris
commented
Jul 11, 2016
@addaleax didn't want to run |
addaleax
commented
Jul 11, 2016
Just wondering if a |
Hah. That would in fact be better C++. Again failed on the context switch from a temporary implementation in JS using |
trevnorris
commented
Jul 11, 2016
Yey! No related failures. Will clean up commits. |
Retrieving the error message along with the error name is useful. So exposing to the JS API. Extend the existing error messages to include more information about the invalid error code. Also add additional UV_ERRNO_MAX range check to ErrName() to help prevent the following comment from libuv documentation on both uv_strerror() and uv_err_name(): Leaks a few bytes of memory when you call it with an unknown error code.
realpath(3) would fail if the symbolic link depth was too deep. If ELOOP is encountered then resolve the path in parts until the entire thing is resolved. This excludes if the number of symbolic links is too deep, or if they are recursive. Fixes: nodejs#7175
The test/benchmarks included also work for the previous JS implementation of fs.realpath(). In case the new implementation of realpath() needs to be reverted, we want these changes to stick around.
jasnell
commented
Aug 8, 2016
@trevnorris ... should this one remain open given that it looks like we're reverting the impl back to the old js impl? |
trevnorris
commented
Aug 9, 2016
@jasnell well, if it's going to take a full major release cycle before libuv is fixed and landed then yeah. probably. though i'd like to hope that it won't. |
jasnell
commented
Aug 9, 2016
Marking this as blocked for now then |
Fishrock123
commented
Oct 14, 2016
This has since been fixed by reverting to js realpath, closing. @trevnorris please let me know if closing this was in error |
Checklist
make -j4 test(UNIX), orvcbuild test nosign(Windows) passesAffected core subsystem(s)
fs, uv
Description of change
Fixes: #7175
This definitely isn't the prettiest code I've written. Want to get feedback while I finish up the tests.
R=@bnoordhuis
R=@saghul