How to change the path where the config files are stored?

[fzPowerUser]

In previous versions of FileZilla server, the XML config files containing user settings was placed into the application install folder by default. Now with the new versions, it seems to be located inside %APPDATA% (or in my case, it seems to be located at "C:\windows\system32\config\systemprofile\AppData\Local\filezilla-server").

How can I change the location and path where these XML config files are stored? I'd like them to all be in one single location, the application install folder. I'm using version 1.1.0

[oibaf]

The server accepts a --config-dir parameter. You can use this parameter when starting the service.

To reconfigure the service so it starts up with that parameter, open a cmd console with Administrator privileges and issue the following command.

Code: Select all

sc config filezilla-server binpath= "\"<FileZilla Server install folder>\filezilla-server.exe\" --config-dir \"<FileZilla Server install folder>\""

Where <FileZilla Server install folder> is the absolute path to the FileZilla Server install folder.

I.e., if FileZilla Server is installed under "C:\Program Files\FileZilla Server", then the above line will look like this:

Code: Select all

sc config filezilla-server binpath= "\"C:\Program Files\FileZilla Server\filezilla-server.exe\" --config-dir \"C:\Program Files\FileZilla Server\""

Quotes and spaces must be input exactly like that.

[ivan]

The server accepts a --config-dir parameter

where i can find list of all parameters ?

[oibaf]

The server accepts a --config-dir parameter

where i can find list of all parameters ?

There's no official documentation about that, as of now, but let me take advantage of this thread to explain how it works in general.

Everything that can be configured via the config files can also be configured via the command line, by means of a syntax that, while mimicking the standard unix-like way of passing arguments, is also able to build lists, maps and all kind of nested structures used within the application.

Taken directly from the comments within file src/filezilla/serialization/archives/argv.hpp:

1. Each --option identifies a node in the tree whose name is "option".
2. If --option is followed by a space and a word that doesn't begin with '--', that word is the option's value and becomes the value of the xml node with the option's name.
3. If --option is followed by a '=' sign, attached to it, and a string, attached to the '=' sign, even if it begin with '--' that string is the option's value and becomes the value of the xml node with the option's name.
4. If ':=' is used instead of '=', then the string that follows becomes the option's value if and only if that option doesn't already have a value.
5. Options can be nested, using the '.' symbol. Each nesting level corresponds to a node in the tree that is the child of the node whose name is the same as the option's previous nesting level.
6. If '@' is used instead of '.', then what follows is the name of an attribute belonging to the tree node whose name is the word that precedes the '@' symbol.
7. An option is defined to be "terminal" if it's the deepest one in the nesting hierarchy.
8. An option that is also an attribute *must* be terminal.
9. If a given nesting level contains a node with the same name as a terminal option's, then the existing node's value gets changed to the option's one, unless the node has the fz:can-override attribute set to "false", in which case a new node gets created with the terminal option's name and appended to the list of nodes for its nesting level.
10. Once a terminal option has its value set, the corresponding node also gets the "fz:can-override" attribute set to false.
11. The net effect of the previous two rules is that an option can be "closed" by declaring that option on the command line, without any associated value: this will set the fz:can-override attribute to false, but will keep its pre-existing value.
12. Closing an option let's one append to that option's level a sibling of that option. This way, lists/vectors/maps can be built, entirely on the command line.
13. Options set on the command line also get the "fz:argv" attribute set to true. This is used by the check_for_unhandled_options() method.

Example:

Code: Select all

program --vec.list.elem 1 --vec.list.elem 2 --vec.list --vec.list.elem 1 --vec.list.elem 2

Produces the following tree

Code: Select all

<?xml version="1.0"?>
<filezilla>
    <vec fz:argv="true">
        <list fz:argv="true" fz:can-override="false">
            <elem fz:argv="true" fz:can-override="false">1</elem>
            <elem fz:argv="true" fz:can-override="false">2</elem>
        </list>
        <list fz:argv="true">
            <elem fz:argv="true" fz:can-override="false">1</elem>
            <elem fz:argv="true" fz:can-override="false">2</elem>
        </list>
    </vec>
</filezilla>

In addition to that, the server currently supports two other arguments: one is the already discussed --config-dir, the other is --write-config. The latter is used to write to file the configuration parameters passed in via the command line, and then exit. A live example of the latter can be found in the windows installer, where this ability is used to set up the server to use the configuration info selected via the installation wizard.

Lines 267 and 409 in pkg/exe/install.nsi.in

Code: Select all

267: ${StartService} filezilla-server '--admin.local_port $V_ServerSettings_Admin_PortNumber $R1 --logger.name:="$INSTDIR\Logs\filezilla-server.log" --logger.enabled_types:=15 --logger.max_amount_of_rotated_files:=5 --write-config'
409: ${AsUser_Open} "filezilla-server-gui.exe" "--server.name Local --server.host 127.0.0.1 --server.port $V_ServerSettings_Admin_PortNumber --write-config"