= File Component
:doctitle: File
:shortname: file
:artifactid: camel-file
:description: Read and write files.
:since: 1.0
:supportlevel: Stable
:tabs-sync-option:
:component-header: Both producer and consumer are supported
:core:
//Manually maintained attributes
:camel-spring-boot-name: file

*Since Camel {since}*

*{component-header}*

The File component provides access to file systems, allowing files to be
processed by any other Camel Components or
messages from other components to be saved to disk.

== URI format

----
file:directoryName[?options]
----

Where `directoryName` represents the underlying file directory.

*Only directories*

Camel supports only endpoints configured with a starting directory. So
the `directoryName` *must be* a directory.
 If you want to consume a single file only, you can use the `fileName`
option, e.g., by setting `fileName=thefilename`.
 Also, the starting directory must not contain dynamic expressions with
`${ }` placeholders. Again use the `fileName` option to specify the
dynamic part of the filename.

[WARNING]
====
*Avoid reading files currently being written by another application*

Beware the JDK File IO API is a bit limited in detecting whether another
application is currently writing/copying a file. And the implementation
can be different depending on the OS platform as well. This could lead to
that Camel thinks the file is not locked by another process and start
consuming it. Therefore, you have to do your own investigation what suites
your environment. To help with this Camel provides different `readLock`
options and `doneFileName` option that you can use. See also
<<File2-Consumingfilesfromfolderswhereothersdropfilesdirectly, Consuming files from folders where others drop files directly>>.
====


// component-configure options: START

// component-configure options: END

// component options: START
include::partial$component-configure-options.adoc[]
include::partial$component-endpoint-options.adoc[]
// component options: END

// endpoint options: START

// endpoint options: END

// component headers: START
include::partial$component-endpoint-headers.adoc[]
// component headers: END

[TIP]
====
*Default behavior for file producer* 

By default, it will override any existing file if one exists with the same name.
====

== Usage

=== Move, Pre Move and Delete operations

By default, Camel will move consumed files to the `.camel` subfolder
relative to the directory where the file was consumed.

If you want to delete the file after processing, the route should be:

[source,java]
----
from("file://inbox?delete=true").to("bean:handleOrder");
----

[NOTE]
====
There is a sample <<File2-ReadingFromADirectoryAndTheDefaultMoveOperation,showing reading from a directory and the default move operation>> below.
====

==== Move, Delete and the Routing process

Any move or delete operations are executed after the routing has completed.
So, during processing of the `Exchange` the file is still located in the inbox folder.

Let's illustrate this with an example:

[source,java]
----
from("file://inbox?move=.done").to("bean:handleOrder");
----

When a file is dropped in the `inbox` folder, the file consumer notices
this and creates a new `FileExchange` that is routed to the
`handleOrder` bean. The bean then processes the `File` object. At this
point in time the file is still located in the `inbox` folder. After the
bean completes, and thus the route is completed, the file consumer will
perform the move operation and move the file to the `.done` sub-folder.

The `move` and the `preMove` options are considered as a directory name.
Though, if you use an expression such as xref:languages:file-language.adoc[File Language],
or xref:languages:simple-language.adoc[Simple], then the result of the expression
evaluation is the file name to be used.
E.g., if you set:

----
move=../backup/copy-of-${file:name}
----

Then that's using the xref:languages:file-language.adoc[File Language] which we
 use to return the file name to be used.
This can be either relative or absolute.
If relative, the directory is created as a subfolder from within the folder where the file was consumed.

==== Move and Pre Move operations

We have introduced a `preMove` operation to move files *before* they
are processed. This allows you to mark which files have been scanned as
they are moved to this subfolder before being processed.

[source,java]
----
from("file://inbox?preMove=inprogress").to("bean:handleOrder");
----

You can combine the `preMove` and the regular `move`:

[source,java]
----
from("file://inbox?preMove=inprogress&move=.done").to("bean:handleOrder");
----

So in this situation, the file is in the `inprogress` folder when being
processed, and after it's processed, it's moved to the `.done` folder.

==== Fine-grained control over Move and PreMove option

The `move` and `preMove` options are Expression-based, so we have the full power of
the xref:languages:file-language.adoc[File Language] to do advanced configuration
of the directory and name pattern.
Camel will, in fact, internally convert the directory name you enter
into a xref:languages:file-language.adoc[File Language] expression.
So, when we use `move=.done` Camel will convert this into:
`${file:parent}/.done/${file:onlyname}`.

This is only done if Camel detects that you have not provided a `${ }` in the option value
yourself.
So when you enter a `${ }` Camel will *not* convert it, and thus
you have the full power.

So if we want to move the file into a backup folder with today's date, as
the pattern, we can do:

----
move=backup/${date:now:yyyyMMdd}/${file:name}
----

==== About moveFailed

The `moveFailed` option allows you to move files that *could not* be
processed successfully to another location such as an error folder of your
choice.
For example, to move the files in an error folder with a timestamp you can use
`moveFailed=/error/${``file:name.noext``}-${date:now:yyyyMMddHHmmssSSS}.${``file:ext`}.

[TIP]
====
See more examples at xref:languages:file-language.adoc[File Language]
====

=== Exchange Properties, file consumer only

As the file consumer implements the `BatchConsumer` it supports batching
the files it polls. By batching, we mean that Camel will add the
following additional properties to the Exchange:

[width="100%",cols="10%,90%",options="header",]
|===
|Property |Description

|`CamelBatchSize` |The total number of files that was polled in this batch.

|`CamelBatchIndex` |The current index of the batch. Starts from 0.

|`CamelBatchComplete` |A `boolean` value indicating the last Exchange in
the batch. Is only `true` for the last entry.
|===

This allows you, for instance, to know how many files exist in this batch
and for instance, let the Aggregator2 aggregate
this number of files.

=== Using charset

The `charset` option allows configuring the encoding of the files on
both the consumer and producer endpoints. For example, if you read utf-8
files and want to convert the files to iso-8859-1, you can do:

[source,java]
----
from("file:inbox?charset=utf-8")
  .to("file:outbox?charset=iso-8859-1")
----

You can also use the `convertBodyTo` in the route. In the example below,
we have still input files in utf-8 format, but we want to convert the
file content to a byte array in iso-8859-1 format. And then let a bean
process the data. Before writing the content to the outbox folder using
the current charset.

[source,java]
----
from("file:inbox?charset=utf-8")
  .convertBodyTo(byte[].class, "iso-8859-1")
  .to("bean:myBean")
  .to("file:outbox");
----

If you omit the charset on the consumer endpoint, then Camel does not
know the charset of the file, and would by default use `UTF-8`. However,
you can configure a JVM system property to override and use a different
default encoding with the key `org.apache.camel.default.charset`.

In the example below, this could be a problem if the files are not in
UTF-8 encoding, which would be the default encoding for read the
files.
In this example when writing the files, the content has already been
converted to a byte array, and thus would write the content directly as
is (without any further encodings).

[source,java]
----
from("file:inbox")
  .convertBodyTo(byte[].class, "iso-8859-1")
  .to("bean:myBean")
  .to("file:outbox");
----

You can also override and control the encoding dynamic when writing
files, by setting a property on the exchange with the key
`Exchange.CHARSET_NAME`. For example, in the route below, we set the
property with a value from a message header.

[source,java]
----
from("file:inbox")
  .convertBodyTo(byte[].class, "iso-8859-1")
  .to("bean:myBean")
  .setProperty(Exchange.CHARSET_NAME, header("someCharsetHeader"))
  .to("file:outbox");
----

We suggest keeping things simpler, so if you pick up files with the same
encoding, and want to write the files in a specific encoding, then favor
to use the `charset` option on the endpoints.

Notice that if you have explicitly configured a `charset` option on the
endpoint, then that configuration is used, regardless of the
`Exchange.CHARSET_NAME` property.

If you have some issues then you can enable DEBUG logging on
`org.apache.camel.component.file`, and Camel logs when it reads/write a
file using a specific charset.
For example, the route below will log the following:

[source,java]
----
from("file:inbox?charset=utf-8")
  .to("file:outbox?charset=iso-8859-1")
----

And the logs:

----------------------------------------------------------------------------------------------------------------------------------------------
DEBUG GenericFileConverter           - Read file /Users/davsclaus/workspace/camel/camel-core/target/charset/input/input.txt with charset utf-8
DEBUG FileOperations                 - Using Reader to write file: target/charset/output.txt with charset: iso-8859-1
----------------------------------------------------------------------------------------------------------------------------------------------

=== Common gotchas with folder and filenames

When Camel is producing files (writing files), there are a few gotchas
affecting how to set a filename of your choice. By default, Camel will
use the message ID as the filename, and since the message ID is normally
a unique generated ID, you will end up with filenames such as:
`ID-MACHINENAME-2443-1211718892437-1-0`. If such a filename is not
desired, then you must provide a filename in the `CamelFileName` message
header. The constant, `Exchange.FILE_NAME`, can also be used.

The sample code below produces files using the message ID as the
filename:

[source,java]
----
from("direct:report").to("file:target/reports");
----

To use `report.txt` as the filename you have to do:

[source,java]
----
from("direct:report").setHeader(Exchange.FILE_NAME, constant("report.txt")).to( "file:target/reports");
----

... the same as above, but with `CamelFileName`:

[source,java]
----
from("direct:report").setHeader("CamelFileName", constant("report.txt")).to( "file:target/reports");
----

And a syntax where we set the filename on the endpoint with the
`fileName` URI option.

[source,java]
----
from("direct:report").to("file:target/reports/?fileName=report.txt");
----

=== Filename Expression

Filename can be set either using the *expression* option or as a
string-based xref:languages:file-language.adoc[File Language] expression in the
`CamelFileName` header. See the xref:languages:file-language.adoc[File Language]
for syntax and samples.

[[File2-Consumingfilesfromfolderswhereothersdropfilesdirectly]]
=== Consuming files from folders where others drop files directly

Beware if you consume files from a folder where other applications write
files too. Take a look at the different `readLock` options to see
what suits your use cases. The best approach is, however, to write to
another folder and, after writing, move the file in the drop folder.
However, if you write files directly to the drop folder, then the option
`changed` could better detect whether a file is currently being
written/copied as it uses a file changed algorithm to see whether the
file size / modification changes over a period of time. The other
`readLock` options rely on Java File API that, sadly, is not always very
good at detecting this. You may also want to look at the `doneFileName`
option, which uses a marker file (_done file_) to signal when a file is
done and ready to be consumed.

=== Done files

==== Using done files

See also section <<File2-WritingDoneFiles,_writing done files_>> below.

If you want only to consume files when a _done file_ exists, then you can
use the `doneFileName` option on the endpoint.

[source,java]
----
from("file:bar?doneFileName=done");
----

It will only consume files from the _bar_ folder if a _done file_ exists in
the same directory as the target files. Camel will automatically delete
the _done file_ when it's done consuming the files.

[NOTE]
====
Camel does not delete automatically the _done file_ if `noop=true` is configured.
====

However, it is more common to have one _done file_ per target file. This
means there is a 1:1 correlation. To do this, you must use dynamic
placeholders in the `doneFileName` option. Currently, Camel supports the
following two dynamic tokens: `file:name` and `file:name.noext` which
must be enclosed in `${ }`. The consumer only supports the static part of
the _done file_ name as either prefix or suffix (not both).


[tabs]
====
Suffix::
+

[source,java]
----
from("file:bar?doneFileName=${file:name}.done");
----
+
In this example, the files will only be polled if there exists a _done file_
with the name `_file name_.done`.
For example:

* `hello.txt`: is the file to be consumed
* `hello.txt.done`: is the associated `done` file

Prefix::
+

[source,java]
----
from("file:bar?doneFileName=ready-${file:name}");
----
+
You can also use a prefix for the _done file_, such as:

* `hello.txt`: is the file to be consumed
* `ready-hello.txt`: is the associated `done` file

====


[[File2-WritingDoneFiles]]
==== Writing done files

After you have written a file, you may want to write an additional _done file_ as a kind of marker,
to indicate to others that the file is finished and has been written.
To do that, you can use the `doneFileName` option on the file producer endpoint.

[source,java]
----
.to("file:bar?doneFileName=done");
----

This will create a file named `done` in the same directory as the
target file.

However, it is more common to have one _done file_ per target file. This
means there is a 1:1 correlation. To do this, you must use dynamic
placeholders in the `doneFileName` option. Currently, Camel supports the
following two dynamic tokens: `file:name` and `file:name.noext`.
They must be enclosed in `${ }`:

[tabs]
====
Prefix and file name::
+
[source,java]
----
.to("file:bar?doneFileName=done-${file:name}");
----
+
This will, for example, create a file named `done-foo.txt` if the target file
was `foo.txt` in the same directory as the target file.

Suffix and file name::
+
[source,java]
----
.to("file:bar?doneFileName=${file:name}.done");
----
+
This will, for example, create a file named `foo.txt.done` if the target file
was `foo.txt` in the same directory as the target file.

File name without the extension::
+
[source,java]
----
.to("file:bar?doneFileName=${file:name.noext}.done");
----
+
Will, for example, create a file named `foo.done` if the target file was
`foo.txt` in the same directory as the target file.

====

[[File2-Usingflatten]]
=== Using flatten

If you want to store the files in the `outputdir` directory in the same
directory, disregarding the source directory layout (e.g., to flatten out
the path), you add the `flatten=true` option on the file producer
side:

[source,java]
----
from("file://inputdir/?recursive=true&delete=true").to("file://outputdir?flatten=true")
----

It will result in the following output layout:

----
outputdir/foo.txt
outputdir/bar.txt
----

=== Writing to files

Camel is also able to write files, i.e., produce files.
In the sample below, we receive some reports on the SEDA queue that we process
before they are being written to a directory.

==== Write to subdirectory using `Exchange.FILE_NAME`

Using a single route, it is possible to write a file to any number of
subdirectories. If you have a route setup as such:

[source,xml]
----
<route>
  <from uri="bean:myBean"/>
  <to uri="file:/rootDirectory"/>
</route>
----

You can have `myBean` set the header `Exchange.FILE_NAME` to values such
as:

----
Exchange.FILE_NAME = hello.txt => /rootDirectory/hello.txt
Exchange.FILE_NAME = foo/bye.txt => /rootDirectory/foo/bye.txt
----

This allows you to have a single route to write files to multiple
destinations.

==== Writing file through the temporary directory relative to the final destination

Sometimes you need to temporarily write the files to some directory
relative to the destination directory. Such a situation usually happens
when some external process with limited filtering capabilities is
reading from the directory you are writing to. In the example below
files will be written to the  `/var/myapp/filesInProgress` directory and
after data transfer is done, they will be atomically moved to
the` /var/myapp/finalDirectory `directory.

[source,java]
----
from("direct:start").
  to("file:///var/myapp/finalDirectory?tempPrefix=/../filesInProgress/");
----

=== Avoiding reading the same file more than once (idempotent consumer)

Camel supports Idempotent Consumer
directly within the component, so it will skip already processed files.
This feature can be enabled by setting the `idempotent=true` option.

[source,java]
----
from("file://inbox?idempotent=true").to("...");
----

Camel uses the absolute file name as the idempotent key, to detect
duplicate files. You can customize this key by
using an expression in the idempotentKey option. For example, to use both
the name and the file size as the key

[source,xml]
----
<route>
  <from uri="file://inbox?idempotent=true&amp;idempotentKey=${file:name}-${file:size}"/>
  <to uri="bean:processInbox"/>
</route>
----

By default, Camel uses an in-memory store for keeping track of
consumed files.
It uses the least recently used cache holding up to 1000
entries. You can plug in your own implementation of this store by using
the `idempotentRepository` option using the `#` sign in the value to
indicate it's a referring to a bean in the Registry
with the specified `id`.

[source,xml]
----
 <!-- define our store as a plain spring bean -->
 <bean id="myStore" class="com.mycompany.MyIdempotentStore"/>

<route>
  <from uri="file://inbox?idempotent=true&amp;idempotentRepository=#myStore"/>
  <to uri="bean:processInbox"/>
</route>
----

Camel will log at `DEBUG` level if it skips a file because it has been
consumed before:

----
DEBUG FileConsumer is idempotent and the file has been consumed before. Will skip this file: target\idempotent\report.txt
----

=== Idempotent Repository

==== Using a file-based idempotent repository

In this section we will use the file-based idempotent repository
`org.apache.camel.processor.idempotent.FileIdempotentRepository` instead
of the in-memory one that is used as default.
This repository uses a first level cache to avoid reading the file
repository. It will only use the file repository to store the content of
the first level cache. Thereby, the repository can survive server restarts.
It will load the content of the file into the first level cache upon
startup. The file structure is basic as it stores the key in
separate lines in the file. By default, the file store has a size limit
of 1mb. When the file grows larger, Camel will truncate the file store,
rebuilding the content by flushing the first level cache into a fresh
empty file.

We configure our repository using Spring XML creating our file
idempotent repository and define our file consumer to use our repository
with the `idempotentRepository` using `#` sign to indicate
Registry lookup:

==== Using a JPA based idempotent repository

In this section, we will use the JPA based idempotent repository instead
of the in-memory based that is used as default.

First we need a persistence-unit in `META-INF/persistence.xml` where we
need to use the class
`org.apache.camel.processor.idempotent.jpa.MessageProcessed` as the model.

[source,xml]
----
<persistence-unit name="idempotentDb" transaction-type="RESOURCE_LOCAL">
  <class>org.apache.camel.processor.idempotent.jpa.MessageProcessed</class>

  <properties>
    <property name="openjpa.ConnectionURL" value="jdbc:derby:target/idempotentTest;create=true"/>
    <property name="openjpa.ConnectionDriverName" value="org.apache.derby.jdbc.EmbeddedDriver"/>
    <property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema"/>
    <property name="openjpa.Log" value="DefaultLevel=WARN, Tool=INFO"/>
    <property name="openjpa.Multithreaded" value="true"/>
  </properties>
</persistence-unit>
----

Next, we can create our JPA idempotent repository in the spring
XML file as well:

[source,xml]
----
<!-- we define our jpa based idempotent repository we want to use in the file consumer -->
<bean id="jpaStore" class="org.apache.camel.processor.idempotent.jpa.JpaMessageIdRepository">
    <!-- Here we refer to the entityManagerFactory -->
    <constructor-arg index="0" ref="entityManagerFactory"/>
    <!-- This 2nd parameter is the name (= a category name).
         You can have different repositories with different names -->
    <constructor-arg index="1" value="FileConsumer"/>
</bean>
----

And yes then we just need to refer to the *jpaStore* bean in the file
consumer endpoint using the `idempotentRepository` using the `#` syntax
option:

[source,xml]
----
<route>
  <from uri="file://inbox?idempotent=true&amp;idempotentRepository=#jpaStore"/>
  <to uri="bean:processInbox"/>
</route>
----

=== Filtering Strategies

Camel supports pluggable filtering strategies. They are described below.

==== Filter using the `GenericFilter`

The `filter` option allows you to implement a custom filter in Java code
by implementing the `org.apache.camel.component.file.GenericFileFilter`
interface.

===== Implementing a GenericFilter

The interface has an `accept` method that returns a boolean.
The meaning of the return values are:

* `true` to include the file
* `false` to skip the file.


There is also a `isDirectory` method on `GenericFile` to inform whether the file is a directory.
This allows you to filter unwanted directories, to avoid traversing down unwanted directories.

===== Using the `GenericFilter`

You can then configure the endpoint with such a filter to skip certain files being processed.

In the sample we have built our own filter that skips files starting
with `skip` in the filename:

And then we can configure our route using the `filter` attribute to
reference our filter (using `#` notation) that we have defined in the
spring XML file:

[source,xml]
----
<!-- define our filter as a plain spring bean -->
<bean id="myFilter" class="com.mycompany.MyFileFilter"/>

<route>
  <from uri="file://inbox?filter=#myFilter"/>
  <to uri="bean:processInbox"/>
</route>
----

==== Filtering using ANT path matcher

The ANT path matcher is based on
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/util/AntPathMatcher.html[AntPathMatcher].

The file paths are matched with the following rules:

* `?` matches one character
* `*` matches zero or more characters
* `**` matches zero or more directories in a path

The `antInclude` and `antExclude` options make it easy to
specify ANT style include/exclude without having to define the filter.
See the URI options above for more information.

The sample below demonstrates how to use it:

[source,java]
----
from("file://inbox?antInclude=**/*.txt").to("...");
----

=== Sorting Strategies

Camel supports pluggable sorting strategies. They are described below.

==== Sorting using Comparator

This strategy it to use the build in `java.util.Comparator` in Java. You can then configure the
endpoint with such a comparator and have Camel sort the files before
being processed.

In the sample, we have built our own comparator that just sorts by file
name:

And then we can configure our route using the *sorter* option to
reference to our sorter (`mySorter`) we have defined in the spring XML
file:

[source,xml]
----
 <!-- define our sorter as a plain spring bean -->
 <bean id="mySorter" class="com.mycompany.MyFileSorter"/>

<route>
  <from uri="file://inbox?sorter=#mySorter"/>
  <to uri="bean:processInbox"/>
</route>
----

[TIP]
====
*URI options can reference beans using the # syntax*

In the Spring DSL route above notice that we can refer to beans in the
Registry by prefixing the id with `#`. So writing
`sorter=#mySorter`, will instruct Camel to go look in the
Registry for a bean with the ID, `mySorter`.
====

==== Sorting using sortBy

Camel supports pluggable sorting strategies. This strategy uses the
xref:languages:file-language.adoc[File Language] to configure the sorting. The
`sortBy` option is configured as follows:


----
sortBy=group 1;group 2;group 3;...
----

Where each group is separated with semicolon. In the simple situations
you just use one group, so a simple example could be:

----
sortBy=file:name
----

This will sort by file name, you can reverse the order by prefixing
`reverse:` to the group, so the sorting is now Z to A:

----
sortBy=reverse:file:name
----

As we have the full power of xref:languages:file-language.adoc[File Language], we
can use some of the other parameters, so if we want to sort by file size,
we do:

----
sortBy=file:length
----

You can configure to ignore the case, using `ignoreCase:` for string
comparison, so if you want to use file name sorting but to ignore the
case, then we do:

----
sortBy=ignoreCase:file:name
----

You can combine ignore case and reverse. However, `reverse` must be
specified first:

----
sortBy=reverse:ignoreCase:file:name
----

In the sample below we want to sort by the last modified file, so we do:

----
sortBy=file:modified
----

And then we want to group by name as a second option, so files with the same
modification time are sorted by name:

----
sortBy=file:modified;file:name
----

Now there is an issue here, can you spot it? Well, the modified timestamp
of the file is too fine as it will be in milliseconds, but what if we
want to sort by date only and then subgroup by name?
Well, as we have the true power of xref:languages:file-language.adoc[File Language],
we can use its date command that supports patterns.
So this can be solved as:

----
sortBy=date:file:yyyyMMdd;file:name
----

Yeah, that is pretty powerful, oh by the way, you can also use reverse
per group, so we could reverse the file names:

----
sortBy=date:file:yyyyMMdd;reverse:file:name
----

=== Using GenericFileProcessStrategy

The option `processStrategy` can be used to use a custom
`GenericFileProcessStrategy` that allows you to implement your own
_begin_, _commit_ and _rollback_ logic.
For instance, let's assume a system writes a file in a folder you should
consume. But you should not start consuming the file before another
_ready_ file has been written as well.

So by implementing our own `GenericFileProcessStrategy` we can implement
this as:

* In the `begin()` method we can test whether the special _ready_ file
exists. The `begin` method returns a `boolean` to indicate if we can
consume the file or not.
* In the `abort()` method special logic can be executed in
case the `begin` operation returned `false`, for example, to clean up
resources etc.
* in the `commit()` method we can move the actual file and also delete
the _ready_ file.

=== Using bridgeErrorHandler

If you want to use the Camel Error Handler to
deal with any exception occurring in the file consumer, then you can
enable the `bridgeErrorHandler` option as shown below:

[source,java]
----
// to handle any IOException being thrown
onException(IOException.class)
    .handled(true)
    .log("IOException occurred due: ${exception.message}")
    .transform().simple("Error ${exception.message}")
    .to("mock:error");

// this is the file route that pickup files. Notice how we bridge the consumer to use the Camel routing error handler
// the exclusiveReadLockStrategy is only configured because this is from a unit test, so we use that to simulate exceptions
from("file:target/nospace?bridgeErrorHandler=true")
    .convertBodyTo(String.class)
    .to("mock:result");
----

So all you have to do is to enable this option, and the error handler in
the route will take it from there.

[IMPORTANT]
====
When using bridgeErrorHandler, then `interceptors`, `OnCompletions`
do *not* apply.
The Exchange is processed directly by the Camel Error Handler, and does not allow
prior actions such as interceptors, onCompletion to take action.
====

=== Debug logging

This component has log level *TRACE* that can be helpful if you have
problems.

== Examples

[[File2-ReadingFromADirectoryAndTheDefaultMoveOperation]]
=== Reading from a directory and the default move operation

By default, Camel will move any processed file into a `.camel`
subdirectory in the directory the file was consumed from.

[source,java]
----
from("file://inputdir/?recursive=true&delete=true").to("file://outputdir")
----

Affects the layout as follows: +
*before*

----
inputdir/foo.txt
inputdir/sub/bar.txt
----

*after*

----
inputdir/.camel/foo.txt
inputdir/sub/.camel/bar.txt
outputdir/foo.txt
outputdir/sub/bar.txt
----

=== Read from a directory and write to another directory

[source,java]
----
from("file://inputdir/?delete=true").to("file://outputdir")
----

=== Read from a directory and write to another directory using a dynamic name

[source,java]
----
from("file://inputdir/?delete=true").to("file://outputdir?fileName=copy-of-${file:name}")
----

Listen to a directory and create a message for each file dropped there.
Copy the contents to the `outputdir` and delete the file in the
`inputdir`.

=== Reading recursively from a directory and writing to another

[source,java]
----
from("file://inputdir/?recursive=true&delete=true").to("file://outputdir")
----

Listen to a directory and create a message for each file dropped there.
Copy the contents to the `outputdir` and delete the file in the
`inputdir`. Will scan recursively into subdirectories. Will lay out the
files in the same directory structure in the `outputdir` as the
`inputdir`, including any subdirectories.


----
inputdir/foo.txt
inputdir/sub/bar.txt
----

It will result in the following output layout:

----
outputdir/foo.txt
outputdir/sub/bar.txt
----

=== Read from a directory and process the message in java

[source,java]
----
from("file://inputdir/").process(new Processor() {
  public void process(Exchange exchange) throws Exception {
    Object body = exchange.getIn().getBody();
    // do some business logic with the input body
  }
});
----

The body will be a `File` object that points to the file that was just
dropped into the `inputdir` directory.

=== Using expression for filenames

In this sample, we want to move consumed files to a backup folder using
today's date as a subfolder name:

[source,java]
----
from("file://inbox?move=backup/${date:now:yyyyMMdd}/${file:name}").to("...");
----

See xref:languages:file-language.adoc[File Language] for more samples.


include::spring-boot:partial$starter.adoc[]
