0

0

By Ivan Rastvorov Following Unfollow Follow   6,394 October 20, 2016 Following Unfollow Follow

Category:

Programming

Dear friends! The key goal of our today’s lesson is to learn how to work with binary data and file system. Node.js contains fs module to work with files, which includes a number of functions for various operations with files and directories.

If we focus on it more carefully, we will see the first specific feature of this module. Almost all functions have two variants: the first one is simply a function’s name, and the second one is its name with Sync.
Sync means “synchronously.” For example, if I call fs.readFile, this fs.readFile will first read it in its full size, then it will call a callback (fs.readFile(filename,[options], callback) and fs.readFileSync will slow down the process execution by Node.js until the file is read. So, such synchronous call is generally used either in console utilities or when the server is initialized, which is a period, when such brakes are quite acceptable. And an asynchronous call is used in those cases, when we want our event loop to work in its full capacity, which means Node.js doesn’t have to wait when a slow disk starts to work and a file gets read.

Let us look at a real example of using this principle. Let’s create file read.js. We connect the fs module and call an asynchronous function readFile:

This function borrows the file name – in our case, this is a path to the current module file – and receives a callback: the first argument is generally an error, the second one is data and the file content. If it were an asynchronous call, it would look like:

Thus, an error would be an exception. But we are going to work only with asynchronous calls further. So, let’s get it started. Pay your attention to the fact that we’ve got not file content within a string, but a specialized buffer object. This buffer object is a highly effective Node.js solution for working with binary data. Technically, buffer is an endless memory area, which is filled here with these data.

Work with the buffer is similar to work with a string. We can get a zero element here:

Or we can get the buffer length:

But unlike to strings that are totally unchangeable in JavaScript, the buffer content can be changed. To do so, our technical materials include a number of methods starting from the most primitive write, which inserts the string to a buffer changing the former to a binary format considering encoding; and ending with various methods adding full, fractional numbers, those of a double format, etc. considering their computerized binary notation.

In this case, we would like to output the file content as a string, that’s why let us modify the buffer string into the call toString by specifying the coding within the brackets, i.e. the table that explains how to transfer bytes into alphabetic symbols. It is utf-8 by default, so we’ll leave it as it is.

Launch it. If I know for sure that I work with strings, I can add coding right here:

Launch. Everything works. In this case, transformation into a string happens right withing the readFile function.

And now let us see, what will happen, if there is an error somewhere. For example, I read a file that does not exist:

I launch it. So, we see an error inside console.error.

I draw your attention to the fact that the error includes the following data. First, the error name. In our case, ‘ENOENT’ means the file does not exist. Second, the digital code: error 34. Both codes are fully cross-platform, which means it does not really matter whether I use Windows, Linux or something else. If a file can’t be found, it is always ‘ENOENT’. So, let us test it: if the code is ENOENT, it will react in one way, but if it isn’t – the reaction will be different:

Launch it. Ok. Everything works.

If you get interested what other errors exist or you want to get the error code decryption in the future, unfortunately, you won’t find it in Node.js documents. You will be able to find it within a libUV source – in our case, inside uv.h . Here various kinds of errors are stored – for example, ENOENT or EACCES. These codes are contained right here because libUV itself is responsible for input-output operations. It transforms various codes of operational systems into cross-platform values. If we know in advance a file does not exist, we can check whether it really does not exist using a special call. For that purpose, we’ve got fs.exists – this call checks whether there is a special path, but it cannot check out what kind of object it is – a file or a directory. For more precise checks there is fs.stat and other variants of this call, which can be analyzed in details in our technical materials.

Generally, simple stat is a right solution. It gets a path and returns an object of a specialized type – fs.Stats – containing details on what is stored there. Here is an example how to use it:

So, I launch it. Console.log is the first one to show true, since it is a file, while the second displayed full information on what is contained following this path. It partly depends on the operational system, file system, but you will generally see the following characteristics: size, mtime and date of creation ctime.

And here is an example of creating a new file that will contain a data string followed by its renaming.

Once the string is renamed, we delete it. Pay your attention to the fact that we check an error in every callback. It means, once the file is created, we always check whether there is an error and how it can be handled. The simplest way to do it is throw. Next we rename and handle it. Every callback should contain error performance because errors can be in various, even unexpected places. If we miss it, we may have no clue later shy the system doesn’t work and where we can find this error.

So, we’ve learnt some basic capabilities of the fs module and some examples of how these capabilities can be applied. This module has a lot of methods. We recommend you to find them in our technical materials in order to understand they do exist.

The lesson code is available here.

The materials for this article were borrowed from the screencast.

We are looking forward to meeting you on our website soshace.com

About the author

Ivan Rastvorov

Registered 01-04-2019 | Last seen long time ago 1

0 Comments | 25 Publications