## Using the file system with Vert.x

The Vert.x `FileSystem` object provides many operations for manipulating the file system.

There is one file system object per Vert.x instance, and you obtain it with `fileSystem`.

A blocking and a non blocking version of each operation is provided. The non blocking versions take a handler which is called when the operation completes or an error occurs.

Here’s an example of an asynchronous copy of a file:

    fs = vertx.file_system()

    # Copy file from foo.txt to bar.txt
    fs.copy("foo.txt", "bar.txt") { |res_err,res|
      if (res_err == nil)
        # Copied ok!
      else
        # Something went wrong
      end
    }

The blocking versions are named `xxxBlocking` and return the results or throw exceptions directly. In many cases, depending on the operating system and file system, some of the potentially blocking operations can return quickly, which is why we provide them, but it’s highly recommended that you test how long they take to return in your particular application before using them from an event loop, so as not to break the Golden Rule.

Here’s the copy using the blocking API:

    fs = vertx.file_system()

    # Copy file from foo.txt to bar.txt synchronously
    fs.copy_blocking("foo.txt", "bar.txt")

Many operations exist to copy, move, truncate, chmod and many other file operations. We won’t list them all here, please consult the `API docs` for the full list.

Let’s see a couple of examples using asynchronous methods:

    require 'vertx/buffer'
    # Read a file
    vertx.file_system().read_file("target/classes/readme.txt") { |result_err,result|
      if (result_err == nil)
        puts result
      else
        STDERR.puts "Oh oh ...#{result_err}"
      end
    }

    # Copy a file
    vertx.file_system().copy("target/classes/readme.txt", "target/classes/readme2.txt") { |result_err,result|
      if (result_err == nil)
        puts "File copied"
      else
        STDERR.puts "Oh oh ...#{result_err}"
      end
    }

    # Write a file
    vertx.file_system().write_file("target/classes/hello.txt", Vertx::Buffer.buffer("Hello")) { |result_err,result|
      if (result_err == nil)
        puts "File written"
      else
        STDERR.puts "Oh oh ...#{result_err}"
      end
    }

    # Check existence and delete
    vertx.file_system().exists("target/classes/junk.txt") { |result_err,result|
      if (result_err == nil && result)
        vertx.file_system().delete("target/classes/junk.txt") { |r_err,r|
          puts "File deleted"
        }
      else
        STDERR.puts "Oh oh ... - cannot delete the file: #{result_err}"
      end
    }

### Asynchronous files

Vert.x provides an asynchronous file abstraction that allows you to manipulate a file on the file system.

You open an `AsyncFile` as follows:

    options = {
    }
    fileSystem.open("myfile.txt", options) { |res_err,res|
      if (res_err == nil)
        file = res
      else
        # Something went wrong!
      end
    }

`AsyncFile` implements `ReadStream` and `WriteStream` so you can pipe files to and from other stream objects such as net sockets, http requests and responses, and WebSockets.

They also allow you to read and write directly to them.

#### Random access writes

To use an `AsyncFile` for random access writing you use the `write` method.

The parameters to the method are:

- `buffer`: the buffer to write.

- `position`: an integer position in the file where to write the buffer. If the position is greater or equal to the size of the file, the file will be enlarged to accommodate the offset.

- `handler`: the result handler

Here is an example of random access writes:

    require 'vertx/buffer'
    vertx.file_system().open("target/classes/hello.txt", {
    }) { |result_err,result|
      if (result_err == nil)
        file = result
        buff = Vertx::Buffer.buffer("foo")
        (0...5).each do |i|
          file.write(buff, buff.length() * i) { |ar_err,ar|
            if (ar_err == nil)
              puts "Written ok!"
              # etc
            else
              STDERR.puts "Failed to write: #{ar_err}"
            end
          }
        end
      else
        STDERR.puts "Cannot open file #{result_err}"
      end
    }

#### Random access reads

To use an `AsyncFile` for random access reads you use the `read` method.

The parameters to the method are:

- `buffer`: the buffer into which the data will be read.

- `offset`: an integer offset into the buffer where the read data will be placed.

- `position`: the position in the file where to read data from.

- `length`: the number of bytes of data to read

- `handler`: the result handler

Here’s an example of random access reads:

    require 'vertx/buffer'
    vertx.file_system().open("target/classes/les_miserables.txt", {
    }) { |result_err,result|
      if (result_err == nil)
        file = result
        buff = Vertx::Buffer.buffer(1000)
        (0...10).each do |i|
          file.read(buff, i * 100, i * 100, 100) { |ar_err,ar|
            if (ar_err == nil)
              puts "Read ok!"
            else
              STDERR.puts "Failed to write: #{ar_err}"
            end
          }
        end
      else
        STDERR.puts "Cannot open file #{result_err}"
      end
    }

#### Opening Options

When opening an `AsyncFile`, you pass an `OpenOptions` instance. These options describe the behavior of the file access. For instance, you can configure the file permissions with the `read`, `write` and `perms` methods.

You can also configure the behavior if the open file already exists with `createNew` and `truncateExisting`.

You can also mark the file to be deleted on close or when the JVM is shutdown with `deleteOnClose`.

#### Flushing data to underlying storage.

In the `OpenOptions`, you can enable/disable the automatic synchronisation of the content on every write using `dsync`. In that case, you can manually flush any writes from the OS cache by calling the `flush` method.

This method can also be called with an handler which will be called when the flush is complete.

#### Using AsyncFile as ReadStream and WriteStream

`AsyncFile` implements `ReadStream` and `WriteStream`. You can then use them with a pipe to pipe data to and from other read and write streams. For example, this would copy the content to another `AsyncFile`:

    output = vertx.file_system().open_blocking("target/classes/plagiary.txt", {
    })

    vertx.file_system().open("target/classes/les_miserables.txt", {
    }) { |result_err,result|
      if (result_err == nil)
        file = result
        file.pipe_to(output) { |ar_err,ar|
          if (ar_err == nil)
            puts "Copy done"
          end
        }
      else
        STDERR.puts "Cannot open file #{result_err}"
      end
    }

You can also use the pipe to write file content into HTTP responses, or more generally in any `WriteStream`.

#### Accessing files from the classpath

When vert.x cannot find the file on the filesystem it tries to resolve the file from the class path. Note that classpath resource paths never start with a `/`.

Due to the fact that Java does not offer async access to classpath resources, the file is copied to the filesystem in a worker thread when the classpath resource is accessed the very first time and served from there asynchronously. When the same resource is accessed a second time, the file from the filesystem is served directly from the filesystem. The original content is served even if the classpath resource changes (e.g. in a development system).

This caching behaviour can be set on the `fileCachingEnabled` option. The default value of this option is `true` unless the system property `vertx.disableFileCaching` is defined.

The path where the files are cached is `.vertx` by default and can be customized by setting the system property `vertx.cacheDirBase`.

The whole classpath resolving feature can be disabled system-wide by setting the system property `vertx.disableFileCPResolving` to `true`.

Note | these system properties are evaluated once when the the `io.vertx.core.file.FileSystemOptions` class is loaded, so these properties should be set before loading this class or as a JVM system property when launching it.

If you want to disable classpath resolving for a particular application but keep it enabled by default system-wide, you can do so via the `classPathResolvingEnabled` option.

#### Closing an AsyncFile

To close an `AsyncFile` call the `close` method. Closing is asynchronous and if you want to be notified when the close has been completed you can specify a handler function as an argument.