Skip to content
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

Feature metadata #144

Merged
merged 2 commits into from
Feb 26, 2016
Merged

Feature metadata #144

merged 2 commits into from
Feb 26, 2016

Conversation

erikkemperman
Copy link
Member

Squashed as requested.

@phated
Copy link
Member

phated commented Jan 15, 2016

@erikkemperman it seems that fchmod can't be used on a file that you don't own. Can you add the same check as getTimes to compare the uid and a test to confirm it is working?

@erikkemperman
Copy link
Member Author

At a glance, there is no test for the check in getTimes yet, either? I will have some time for this tomorrow.

@erikkemperman erikkemperman force-pushed the feature-metadata branch 2 times, most recently from 91d6e19 to 35cff30 Compare January 17, 2016 16:29
@erikkemperman
Copy link
Member Author

Several changes, including the guard against calling fchmod when we don't own the file. I have no idea how to unit test this though, we're not allowed to chown a file in order to verify this guard works. Ideas?

The last couple of commits are smaller changes I think are improvements, but for the moment I'll leave them unsquashed for easier review.

@erikkemperman
Copy link
Member Author

Note, there are of course still those two tests that fail against the version of vinyl with the contents getter/setter changing stat.xtime. Because that change is already in master, I propose to get that sorted out first -- i.e. in the corresponding PR -- before contemplating this one.

@erikkemperman erikkemperman force-pushed the feature-metadata branch 5 times, most recently from a297ca5 to 61cef07 Compare January 18, 2016 12:09
@phated
Copy link
Member

phated commented Jan 18, 2016

@erikkemperman we don't rely on the master branch of vinyl so I don't know why they would be failing

@phated
Copy link
Member

phated commented Jan 26, 2016

@erikkemperman can you revert some of the changes that were added to handle the vinyl changes I've now removed. I'd like to get this in but it got a lot more complicated with those workarounds.

@erikkemperman
Copy link
Member Author

@phated I've tried to keep the changes related to the now removed vinyl changes in a separate PR, here. If there's anything in here you'd rather not have I can of course remove those, but I believe these commits are orthogonal to the vinyl stuff.

@phated
Copy link
Member

phated commented Jan 26, 2016

@erikkemperman ah, I had thought the last 4-5 commits were addressing things from the vinyl changes.

@erikkemperman
Copy link
Member Author

@phated No they're just tweaks on @piranna and my efforts that I kept separate for the moment. I think they are slight improvements, especially the commit that makes the stat post-dest reflect the file on disk, which ought to keep piping onto dest equivalent to having a new src on that file.

Note however that the other PR, which is now mostly pointless until the vinyl issue is resolved, does contain as requested a more or less unrelated commit to address the intermittently failing tests, here.

I didn't have any time the last week or so, but still think the vinyl issue deserves some thought, would love some feedback on that issue.

@phated
Copy link
Member

phated commented Jan 26, 2016

@erikkemperman it definitely needs more thought and discussion. However, can you submit a separate PR with the fix to the failing tests? I'd like to get that merged.

// Check if mode needs to be updated
var modeDiff = 0;
if (typeof file.stat.mode === 'number') {
modeDiff = (file.stat.mode ^ stat.mode) & MASK_MODE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the ^ operator? I've never encountered it before

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, I guess I betrayed my C origins there. It's a nice operator to get bit-difference.

@erikkemperman
Copy link
Member Author

Sure thing, will do that when I get on campus in an hour or so.

As to the commits here, I kept them separate for easier review but should probably squash at some point.

var writeDir = require('./writeDir');
var writeStream = require('./writeStream');
var writeBuffer = require('./writeBuffer');
var writeSymbolicLink = require('./writeSymbolicLink');

// TODO include sticky/setuid/setgid, i.e. 7777?
var MASK_MODE = parseInt('0777', 8);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see #103 and #134

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@phated Not sure what you mean... If you meant dropping the zero, so it would leave parseInt('777', 8) -- that would do the exact same thing, since it is the same number...

I added the leading zero to emphasize we are now actively ignoring any sticky/setuid/setgid bits that users might have set on stat.mode. Notice that this does not set those bits on extant files on disk to 0 -- all this mask does is ignore any bits on stat.mode that are not rwx flags in building the argument to fchmod. And the TODO comment questioned if we wanted to allow users to set those other bits as well.

Either way, it is separate from the issue you linked, although if we were to allow these bits to be set by the user, and reflected on disk by dest, then there should be a test for it which doesn't use the realMode function of course (awkward description of what it does, acually).

@erikkemperman
Copy link
Member Author

@piranna @phated The fix for the intermittently failing tests would have to be altered again if this PR were merged. So I would propose getting this out the way first and then addressing those?

Let me know if I should remove any commits from this PR, or rebase/squash.

EDIT: Sorry @piranna, auto-complete got me. I meant to address @phated.

@piranna
Copy link
Contributor

piranna commented Jan 26, 2016

EDIT: Sorry @piranna, auto-complete got me. I meant to address @phated.

Ok, don't worry :-)

@phated
Copy link
Member

phated commented Jan 28, 2016

@erikkemperman feel free to squash, I am working on some cleanup against this branch currently but can stash and apply after the rebase.

@erikkemperman
Copy link
Member Author

@phated Done! Thanks for being patient, this whole thing took a good while. Once merged I will adapt and submit the fix for intermittently failing atime/mtime tests.

@phated
Copy link
Member

phated commented Jan 28, 2016

@erikkemperman one more thing, we are writing a lot of functions that take the file descriptor and the vinyl file object - what do you think about attaching the file descriptor to the vinyl object while we are passing it through the vinyl-fs machinery and then removing it when done? This would be very similar to how node's fs.WriteStream works

@erikkemperman
Copy link
Member Author

@phated I inlined some of those functions, like times and mode, so they would have some of their operands in scope and not have to be passed everything. But that won't work across module boundaries obviously.

So you're suggesting to have the various writeXXX modules do file.fd = ... before calling the written callback, and then to have each of them do delete file.fd in their close callback?

I guess I don't see why not, but then I also don't really mind a separate argument in what is after all an internal contract.

@erikkemperman
Copy link
Member Author

@phated Would it be a completely ludicrous idea to de-couple the opening/closing of filedescriptors, i.e. have a separate utility which handles this stuff? That might do lazy closing or even predictive opening? I imagine it is pretty common to have intermediate (but persistent) files, and such cases might benefit from subsequent pipes discovering that its file still has a handle.

@phated phated mentioned this pull request Jan 28, 2016
@phated phated merged commit 90a1189 into gulpjs:master Feb 26, 2016
@phated
Copy link
Member

phated commented Feb 26, 2016

Finished by #151 and published as 2.3.2 - Thanks for all your work on this @erikkemperman!

@erikkemperman erikkemperman deleted the feature-metadata branch May 12, 2016 13:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants