-
-
Notifications
You must be signed in to change notification settings - Fork 156
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
Fix mode comparison #62
Fix mode comparison #62
Conversation
got a test? |
Do you mean a test to prove current implementation breaks, or that it works in the PR ? |
@Meroje - both, a test that fails currently and passes after this PR |
ac3fbe3
to
ba57ce7
Compare
I've got a failing test here, passing on this pull request. |
if (currentMode === file.stat.mode) { | ||
var currentMode = (st.mode & parseInt('0777', 8)); | ||
var expectedMode = (file.stat.mode & parseInt('0777', 8)); | ||
if (currentMode === expectedMode) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm this part doesnt click with me. if the mode is the same then the file contents wont get updated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
parseInt is just there for readability, parseInt('07777', 8) would give 4095.
I changed it to 0777 to remove special bits, for example :
- given a folder with sticky bit and setuid (5722)
- if you then make a file with mode 644, it will become 5644
- as of master,
currentMode === file.stat.mode
evaluates to false - vinyl-fs then tries to chmod the file, which fails when you are not the owner
My opinion is to let the filesystem handle the special bits and just deal with the actual permissions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Meroje That wasn't my concern at all, not sure where that came from. My concern is that this is skipping file writes if the mode is the same, instead it should just not pass a mode into the file write if the mode is the same
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file is written before the chmod check, written() is the callback of the write* https://github.com/wearefractal/vinyl-fs/blob/ba57ce76e978850f79f78bba9b8aa1a73ac5fb2f/lib/dest/writeContents/index.js#L10-22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah sorry I misread the diff - saw line 52 as fs.writeFile
This is causing a failing test for me locally
|
Just saw it, the the chmod changes to 01722 on stream.end. |
@Meroje PR? |
It seems this is an osx thing, the test still passes on my ubuntu work machine, I will just remove the chmod equal expectation. |
It has been shown in gulpjs#62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
It has been shown in #62 this bit can be platform specific and is unreliable, testing fs.chmod is not called will be enough.
Related to #61, I found that the actual issue is currentMode gets its flags stripped by the bitwise comparison, but not the destination mode. This adds bitwise comparison to the dest mode to fix detection of different modes.