-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate flaky test-fs-copyfile #15394
Comments
It looks like the reported file permissions are not identical. @jasnell when you see this error, are you able to verify if the copied file has the correct permissions? I'm curious if this is a bug in the copy code, or a bug in the test. |
I can reproduce this; the files do get different permissions. This should be the relevant output: mkdir("/home/sqrt/src/node/test/tmp", 0777) = 0
open("/home/sqrt/src/node/test/tmp/copyfile.out", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 12
close(12) = 0
open("/home/sqrt/src/node/test/fixtures/a.js", O_RDONLY|O_CLOEXEC) = 12
fstat(12, {st_mode=S_IFREG|0644, st_size=1469, ...}) = 0
open("/home/sqrt/src/node/test/tmp/copyfile.out", O_WRONLY|O_CREAT|O_CLOEXEC, 0100644) = 13
sendfile(13, 12, [0] => [1469], 1469) = 1469
close(12) = 0
close(13) = 0
open("/home/sqrt/src/node/test/fixtures/a.js", O_RDONLY|O_CLOEXEC) = 12
fstat(12, {st_mode=S_IFREG|0644, st_size=1469, ...}) = 0
read(12, "// Copyright Joyent, Inc. and ot"..., 1469) = 1469
close(12) = 0
stat("/home/sqrt/src/node/test/fixtures/a.js", {st_mode=S_IFREG|0644, st_size=1469, ...}) = 0
open("/home/sqrt/src/node/test/tmp/copyfile.out", O_RDONLY|O_CLOEXEC) = 12
fstat(12, {st_mode=S_IFREG|0664, st_size=1469, ...}) = 0
read(12, "// Copyright Joyent, Inc. and ot"..., 1469) = 1469
close(12) = 0
stat("/home/sqrt/src/node/test/tmp/copyfile.out", {st_mode=S_IFREG|0664, st_size=1469, ...}) = 0 I’m not seeing any part of the copy code that would make sure the target file gets the original file mode. |
@cjihrig Yes, but that only applies to the case in which the file is created, not the one in which it is overwritten (i.e. the one in the test file) |
Ah. Yea, it looks like a |
@addaleax does this commit fix the problem for you? |
@cjihrig Looks that way 👍 And makes sense, too. I think both behaviours could make sense depending on the actual use case, though… |
What use cases do you have in mind? |
@cjihrig I think I remember cases where I had applications write history files (à la idk, it was nothing more than a mild annoyance. I guess all I’m saying is, sometimes people give their files a certain mode for a reason, and sometimes (a lot of the time?) copying should respect that, since the semantics of a file and therefore its security properties are usually defined via its path, not where the contents were copied from. |
I agree that copying should retain the original mode. You said both behaviours could make sense. I guess my question is, when would you not want to copy the mode in a standard copy operation? I know Apple's |
@cjihrig Uh, which one are you agreeing with? The problem is that there can be two different “original” file modes, and there is no generic way to tell which mode is the desired one. |
I'm only referring to the case of |
Yeah, maybe to use more technical terms, I think sometimes you want the effect of |
Ok, now we're clear. Yea, I'm not currently trying to solve for |
This commit introduces fchmod() in uv_fs_copyfile() to set the mode of the destination file. Refs: nodejs/node#15394 PR-URL: libuv#1547 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This test isn't flaky, it's platform dependent and has been failing 100% of the time for me for the last three weeks. Since this feature exists on v8.x branch it should either be fixed soon or be removed until it can be fixed. |
It should be fixed by the next libuv update. |
This is a |
Any ETA on next libuv release? I also see this every time when running tests (on Linux). |
Aiming for tomorrow or the day after. You can try applying libuv/libuv@eaf25ae locally and see if it solves the problem for you. |
@cjihrig Yes, that seems to fix it for me. |
Refs: nodejs#15380 Refs: nodejs#15683 Fixes: nodejs#15394 Fixes: nodejs#15770 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: nodejs#15745 Refs: nodejs#15380 Refs: nodejs#15683 Fixes: nodejs#15394 Fixes: nodejs#15770 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: nodejs/node#15745 Refs: nodejs/node#15380 Refs: nodejs/node#15683 Fixes: nodejs/node#15394 Fixes: nodejs/node#15770 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Ping @cjihrig ... seeing some flakiness in the test. This is the second time I've seen this running locally on Ubuntu.
The text was updated successfully, but these errors were encountered: