The move() method takes a directory and a file name as its arguments.
You might calculate the filename in one of the following ways:

1
2
3
4
5
6
7
8
9
10

// use the original file name$file->move($dir,$file->getClientOriginalName());// compute a random name and try to guess the extension (more secure)$extension=$file->guessExtension();if(!$extension){// extension cannot be guessed$extension='bin';}$file->move($dir,rand(1,99999).'.'.$extension);

Using the original name via getClientOriginalName() is not safe as it
could have been manipulated by the end-user. Moreover, it can contain
characters that are not allowed in file names. You should sanitize the name
before using it directly.

Read How to Upload Files for an example of how to manage a file
upload associated with a Doctrine entity.

If true, any errors for this field will be passed to the parent field
or form. For example, if set to true on a normal field, any errors for
that field will be attached to the main form, not to the specific field.

Imagine you have a custom method named matchingCityAndZipCode() that validates
whether the city and zip code match. Unfortunately, there is no "matchingCityAndZipCode"
field in your form, so all that Symfony can do is display the error on top
of the form.

With customized error mapping, you can do better: map the error to the city
field so that it displays above it:

If the violation is generated on a property or method of a class, its
path is simply propertyName;

If the violation is generated on an entry of an array or ArrayAccess
object, the property path is [indexName];

You can construct nested property paths by concatenating them, separating
properties by dots. For example: addresses[work].matchingCityAndZipCode;

The right side contains simply the names of fields in the form.

By default, errors for any property that is not mapped will bubble up to the
parent form. You can use the dot (.) on the left side to map errors of all
unmapped properties to a particular field. For instance, to map all these
errors to the city field, use:

Sets the HTML attributes for the <label> element, which will be used
when rendering the label for the field. It's an associative array with HTML
attribute as a key. This attributes can also be directly set inside the
template:

Configures the string used as the label of the field, in case the label
option was not set. This is useful when using
keyword translation messages.

If you're using keyword translation messages as labels, you often end up having
multiple keyword messages for the same label (e.g. profile_address_street,
invoice_address_street). This is because the label is build for each "path"
to a field. To avoid duplicated keyword messages, you can configure the label
format to a static value, like: