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

Issue #654 working on adding feature fs.watchFile() #748

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

andrewkoung
Copy link
Contributor

Just putting a PR up of my current progress. Feel free to let me know if there could be improvements as I go.

Copy link
Contributor

@humphd humphd left a comment

Choose a reason for hiding this comment

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

Did a read through of this, and left a bunch of comments. Nice working getting going on this so quickly. Let me know if what I wrote brings up more questions for you.

src/filesystem/interface.js Outdated Show resolved Hide resolved
src/filesystem/interface.js Outdated Show resolved Hide resolved
src/filesystem/interface.js Outdated Show resolved Hide resolved
src/filesystem/interface.js Outdated Show resolved Hide resolved
fs.stat(filename, function(err, stats) { prevStat = stats});

//stores interval return values
statWatchers.set(filename, value);
Copy link
Contributor

Choose a reason for hiding this comment

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

Question: what do we do if there is already a watcher in here for this filename? Probably we need an array of intervals for each filename vs. assuming it will only be one? That will complicate removing it. Need to ponder this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If there's a watcher already associated with the filename, maybe it shouldn't it be ignored. There would be a setInterval() that's associated with that filename won't there be?

var value = setInterval(function() {
fs.stat(filename, function(err, stats) {
if(err) {
console.log(err);
Copy link
Contributor

Choose a reason for hiding this comment

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

This isn't good enough. We'll have to deal with it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Any errors handling in nodejs seems to be happening in the highlighted area
image
I tried to analyze the start method, but it seems to be too complex for me with the terminology being used here, but I believe the highlighted portion below is what's important.
image

Copy link
Contributor

Choose a reason for hiding this comment

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

Node is able to throw the error here because they are doing the initial stat synchronously, so the ultimate recipient of the throw would be the caller of fs.watchFile. We can only do asynchronous calls in Filer and the Browser (i.e., we can't block on access to IndexedDB), so throwing doesn't make as much sense for us.

Another problem I see is that node is returning the stat object it gets back from that synchronous call. We also can't do this.

I'm not 100% sure what the right approach is here. Perhaps we need to kill the interval and have the watcher just become a no-op if there is an error? Maybe logging an error to the console in addition does make sense. Perhaps you could do:

console.warn([Filer Error] fs.watchFile encountered an error with ${path}: ${err.message})

console.log(err);
}
//Store the current stat
currStat = stats;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is happening too early. Do you not need:

  1. Move currStat to prevStat
  2. Move stats to currStat
  3. Diff the inner values of the objects (not reference equality)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought the order makes sense in this case because initial prevStat and currStat are undefined, so I set an initial stat value to prevStat. In which I then set the stats coming from fs.stat to currStat since it's undefined. In which does a compare and then sets current to prev.

Copy link
Contributor

Choose a reason for hiding this comment

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

Could be. Let's circle back to this when you get deeper into it.

src/filesystem/interface.js Outdated Show resolved Hide resolved
it('should get a change event when writing a file', function(done) {
const fs = util.fs();

const watcher = fs.watchFile('/myfile.txt', function(event, filename) {
Copy link
Contributor

Choose a reason for hiding this comment

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

watchFile doesn't return a value, so you can drop const watcher =

Copy link
Contributor

Choose a reason for hiding this comment

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

Question: what does node.js do when you watchFile a file that doesn't exist yet? Your code above will break when you do the initial stat, and it gets an ENOENT error.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Node attempts to receive the watcher using this line here stat = statWatchers.get(filename);. If there is no value associated with the key, it'll return undefined. It does a conditional check to see if the stat variable is undefined and create a new watcher and then assign a value to the key. Whether the stat variable was undefined or defined, it lastly attaches a listener stat.addListener('change', listener);.

Copy link
Contributor

Choose a reason for hiding this comment

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

So we have a choice to make in this case: we either duplicate node's use of stat on an internval, or we alter the way watchFile works internally to just call into watch, which uses event based monitoring vs. polling. The upside to the latter is that it already works.

@codecov-io
Copy link

codecov-io commented Mar 25, 2019

Codecov Report

Merging #748 into master will decrease coverage by 17.72%.
The diff coverage is 88%.

Impacted file tree graph

@@             Coverage Diff             @@
##           master     #748       +/-   ##
===========================================
- Coverage   86.88%   69.16%   -17.73%     
===========================================
  Files          16       16               
  Lines        1739     1764       +25     
===========================================
- Hits         1511     1220      -291     
- Misses        228      544      +316
Impacted Files Coverage Δ
src/filesystem/interface.js 84.12% <88%> (-9.17%) ⬇️
src/shell/shell.js 5.83% <0%> (-82.5%) ⬇️
src/shell/environment.js 22.22% <0%> (-77.78%) ⬇️
src/fs-watcher.js 23.07% <0%> (-69.24%) ⬇️
src/filesystem/implementation.js 78.69% <0%> (-5.44%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4aae538...babe89c. Read the comment docs.

src/filesystem/interface.js Outdated Show resolved Hide resolved
expect(typeof fs.watchFile).to.equal('function');
});

/*
Copy link
Contributor

Choose a reason for hiding this comment

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

We need a bunch more tests here, can you expand this please?

Copy link
Contributor

@humphd humphd left a comment

Choose a reason for hiding this comment

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

Left some more feedback. We also need to update the README to add the docs for this method. Follow the example of other methods on that page, in terms of what's needed.

src/filesystem/interface.js Outdated Show resolved Hide resolved
src/filesystem/interface.js Outdated Show resolved Hide resolved
src/filesystem/interface.js Outdated Show resolved Hide resolved
});
},
interval
);
Copy link
Contributor

Choose a reason for hiding this comment

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

Indents here seem wrong, these 3 lines shouldn't all line up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought so too, but I checked the spacings and it looked right, also the linting will fail if I change it.


fs.watchFile('/myfile', function(prev, curr) {
expect(prev).to.exist;
expect(curr).to.exist;
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's do more than just check if the objects exist. We'd expect them to exist, and also to match what a stat object looks like, see https://github.com/filerjs/filer/blob/master/src/stats.js#L10.

Some other tests that I can think of:

  • if you watchFile a file, and then write to it, your listener should get called
  • We'd want to see that the stats (prev vs. curr) do in fact change as the file changes.
  • What happens if we delete a file?
  • Does watchFile work across symlinks?
  • Is the interval value passed by the user honoured in the tests? What if they set another value, do we stick to that timing?

There are more we could do, but at the very least, we need proof that this is working as expected.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've worked on creating some tests for half the points mentioned, but I'm going to have to figure out the logic to test the ones I haven't covered.

Copy link
Contributor

@humphd humphd left a comment

Choose a reason for hiding this comment

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

I haven't had enough time to play with this extensively yet, but I've done another pass over the code. I still think the tests need to be fleshed out more. We should be doing more checks on the actual contents of prev/curr to see what they contain, and if the values make sense based on what we've done with the files.

I've also left some other notes.

if(intervalValue) {
return;
}
else {
Copy link
Contributor

Choose a reason for hiding this comment

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

No else after return. Get rid of this and unindent the code below.

@@ -206,6 +206,60 @@ function FileSystem(options, callback) {
return watcher;
};

//Object that uses filenames as keys
const statWatchers = new Map();
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry to flip back and forth on this, but I'm not clear what benefit we're gaining from Map here over {} for potential loss in compatibility. Can we switch back to {} instead?

const statWatchers = new Map();

this.watchFile = function (filename, options, listener) {
let prevStat, currStat;
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably call Path.normalize(filename) on filename before we use it internally.

return;
}
else {
fs.stat(filename, function (err, stats) {
Copy link
Contributor

Choose a reason for hiding this comment

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

There's some kind of timing bug here. You do a stat, and then inside the callback you start your interval, but never seem to call stat again in that interval's callback. Each interval should recall stat, so you have updated values for prev/currStat.

Also, this raises the question about the interval's lower bounds. There is some amount of time that a stat will take to execute. We shouldn't trigger another one before it's done. Probably we should ignore requests for interval to be lower than 5007 and just use that as our floor.

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