Known Issues
The following issues and limitations are known to exist in ExpeDat 1.12E. Many are scheduled to be addressed in future releases. If any of these issues are of importance to you, please contact DEI Technical Support for information about work-arounds or feature updates.
Individual files transferred by ExpeDat must be less than 8 exabytes each, or the maximum file size supported by the host operating system. The total size of all files transfered per client session must be less than 16 exabytes. The maximum number of files which can be transferred in a single session is approximately one million for MTPexpedat or DropDat, and approximately eight million for movedat or syncdat, depending on the amount of available system memory (RAM).
Certain characters should not be used in file and folder names because they have special meaning on some platforms. When transferring files between different platforms is is possible for a file name which is valid in one context to cause problems in another. Avoid the following characters in file names:
/ \ : * ? " ' ` ; ( ) [ ] & | ! ~ { } @ $
It is also best to avoid spaces in file and folder names, particularly when using Packaging or Action Scripts.
For example, if you try to upload a file named "recipes:recent" to a Windows NTFS filesystem, the file or its contents may seem to disappear and servedat may log an error because Windows reserves the ':' character for Alternate Data Streams.
On most platforms, non-ASCII characters will be encoded as UTF-8 extended characters. This will generally work within ExpeDat, but care must be taken to ensure that any Packaging scripts, Action Scripts, or shell scripts using movedat are able to properly handle UTF-8 extended characters.
Resuming an Upload with Compression
When resuming an interrupted upload, compression cannot be used. To resume an upload, either compression must be disabled or the upload must be restarted. This will be done automatically if the client is non-interactive.
The MTPexpedat GUI does not currently support dragging remote files to a local destination. Instead, users can drag a local folder into the local browser pane to select that folder as the destination.
Dragging local files to the MTPexpedat GUI will select those files in the local file browser. If the dragged files are contained in multiple folders, only the those in one of the folders will be displayed.
Listing a very large directory, either locally or remotely, may temporarily reduce the performance of any downloads occurring at the same time.
The ExpeDat server takes steps to ensure that files being uploaded are not written to or read from by other transactions. However, the mechanisms for this protection are highly dependent upon the operating environment and are not perfect. In particular, files on network storage devices may be susceptible to modification by other programs while in use. Users should take care not move or modify files which may be actively transferring.
Compression can negatively affect performance, particularly if the data being transferred is encrypted or already compressed. Compression should only be used if the data being transferred is known to be compressible. See Tech Note 0014 for more details about compression.
Information about the progress and speed of a file transfer may not be accurate when compression is being used. The server will log the amount of data actually transferred across the network (after compression). If a compressed transfer is interrupted, the amount received may not match the amount sent due to buffering.
Clients may report transfer progress which includes data transferred in a previous session. The server logs only count the data moved during the current session.
Immediately after successful completion of a compressed Send, MTPexpedat's listing of the remote directory may incorrectly display the temporary files instead of the actual completed file. Refreshing the listing by clicking "List" will correct the display.
Operating System Under-Reports Progress
During file transfer, some operating environments may report the size of the arriving file as being much smaller than it actually is. This is most notable with Windows Server 2008 running in an EC2 instance, but may occur on other systems as well. Once the transfer has stopped, the operating system should show the correct size of the file.
Accessing files and directories via symbolic links may produce unexpected results. In order to access the target of a symbolic link, the permissions of the link's parent directory, the link itself, the target's parent directory, and the target itself all must permit access.
Attempting to download a link which points to a directory may result in an error or a zero length file. To list a directory pointed to by a symbolic link in movedat, place an explicit "/" character after the link name. To list a directory pointed to by a symbolic link in MTPexpedat, type its name in the remote path field and click the "List" button.
In a unix shell environment, the syntax "path1/symlink/../path2/" would access the directory "path2" in the parent directory of the symlink target. Using such a path via servedat will instead access the directory "path2" in the parent directory of the symlink itself. In other words, the path would be resolve to "path1/path2/".
Irregular files cannot be targeted as the destination of a Send. If an irregular file (symbolic link, device, socket, pipe, etc.) already exists at the destination path, then the upload will fail with an "Object Unavailable" error. See the movedat and MTPexpedat documentation for details.
Different formats are used to store information about partial transfers.
The server stores partial uploads using "-sv.tmp" and "-sv.met" files. See the Upload Status chapter for details.
The Windows clients store partial downloads using ".TMP" and ".CHK" files. All other clients store partial downloads using a suffix of the form "#00000000.TMP". If the NoCheck option is enabled, the movedat client will download directly to a target file.
If a transaction fails while the server is under heavy load and the network path is experiencing packet loss, a client may receive a "Lost Transaction" error instead of the exact error message. The exact error message will appear in the server logs.
Missing Error Message for Failed Compressed Send
A compressed send may fail even after all of the data has been successfully uploaded to the server. For example, the disk might become full before the data has been completely decompressed. In this case, the client may incorrectly report success while the actual error will appear in the server logs.
Restarting the server via SIGHUP, which is necessary to reload the configuration and private authentication files, will interrupt any active transactions. Interrupted transactions may still be resumed.
Folders can only be deleted if they are emtpy. Mass deletion of a folder's contents is not yet supported.
Remote directories selected using the movedat wild-card option are not currently subject to hierarchial processing. To transfer the contents of such remote directories, they must be explicitly named on the command line.