virtualFileSystems Element

VirtualFileSystems (VFS) are a mechanism made available to applications enabling them to obtain physical file system abstraction.

It is possible to create C:, D:, etc. disk Units including within the context of hosting the web application on a POS-IX system for example.

VirtualFileSystems root declaration. HOME and TEMP VFS are mandatory.

</virtualFileSystems>

Advanced example:

</virtualFileSystems>

↑ Top of page

Attribute	Value	Notes
name	VFS name.	Required. By convention, the path to the VFS files is name:/path/file. Separators / and \ are both supported.
fileSystemProviderClassName	VFS implementation class.	Required. The com.hardis.wagon.impl.vfs.WagonDefaultFileSystem implementation provides access to the server machine's standard file system. The com.hardis.wagon.s3.vfs.WagonS3FileSystem implementation provides access to a server implementing the Amazon S3 protocol (amazon cloud, minio cloud).
rootPath	Real physical path.	Required. There are macros for making rootPaths dynamic: - {userid}: will be dynamically substituted by the name of the connected user, - {sessionid}: will be dynamically substituted by a unique session ID, - {java.io.tmpdir}: refers to the option -Djava.io.tmpdir of the jvm. - {webapp.rootdirectory}: refers to the root of the web application. For security reasons, it is preferable not to reference the root directly and to prefer a sub-directory. - in general, the ${VARIABLE} syntax will be replaced by the value of the "VARIABLE" Java system property if it is defined (e.g. via DVARIABLE=value on Java command line).
createOnStartup	"true" or "false"	Optional. Default value: "false". Only works with a rootPath using a {userid} or {sessionid} macro. Dynamically creates the path on the physical file system.
deleteOnExit	"true" or "false"	Optional. Default value: "false". Only works with a rootPath using a {userid} or {sessionid} macro. Recursively removes a dynamically created tree structure.
visible	"true" or "false"	Optional. This option is supported for backward compatibility. It is replaced by the UiDisplay access privilege (which takes priority when both options are specified).

Access privileges management

By default, users have all privileges on files and directories under the defined VFSes.

However, privileges can be indicated in VFSes.

There are two categories of privileges: standard access privileges which apply even to the internal actions of programs and access privileges which correspond to the actions proposed by Adelia boxes working in the VFS (privileges which have names starting with "Ui"): boxes displayed by VaToolBxFileSelection, VaToolBXOpenDirSelection, VaToolBxOpenFileMultiSelection, VaToolBxSaveFileSelection functions and the file explorer.

These privileges are defined by a parameters section included in the virtualFileSystem section:

....

</virtualFileSystem>

Possible values:

true: privilege always granted in the VFS. Default value.

false: privilege never granted in the VFS.

user_role_name: privilege granted in the VFS only to users with this role.

Name of privilege	Description
read	Privilege managing read access to the VFS.
write	Privilege managing write access to the VFS.
UiDisplay	Privilege managing the display of the VFS in Adelia boxes working on the VFS. Replaces the "visible" attribute specification.
UiUpload	Privilege managing the action of uploading a file onto the VFS in Adelia boxes working in the VFS.
UiDownload	Privilege managing "Download" and "Display" actions on a VFS file in Adelia boxes working in the VFS.
UiCreate	Privilege managing the action of creating a new document or folder in the VFS in Adelia boxes working in the VFS.
UiDelete	Privilege managing the action of deleting a file or folder from the VFS in Adelia boxes working in the VFS.
UiRename	Privilege managing the action of renaming a file or folder from the VFS in Adelia boxes working in the VFS.

NB: execution privileges can be tested using the VaToolBxCloudCheckVFSPrivilege function.

Example:

<\parameters>

<\virtualFileSystem>

N.B. : it is possible to indicate an optional "substituteValues" attribute (boolean type, default value: false) in the "parameters" element.

If this attribute is present and equal to "true", the ${VARIABLE} syntax will be replaced in the parameters value ("value" attribute of "item" elements) by the value of the "VARIABLE" Java system property if it is defined (e.g. via -DVARIABLE=value on the Java command line).

The value remains the same if the system property does not exist.

In the following example:

The "tempDir" parameter will be replaced at execution by the path of the machine's temporary directory.

↑ Top of page