Advanced Topics
Note: This is the print view with all the Reference Manual pages on one page. The paginated version is available here, if you prefer that.
1. Stopping, Resuming and Retrying Uploads
Normally, Quick Upload will attempt to upload each file twice before reporting the upload as having failed. There are a variety of reasons an upload may fail, including bad network connections, failing hardware, the server running out of disk-space, and so on.
When an upload of a file or metadata fails, users can force a retry by changing the target location and/or metadata. If uploading the file failed then changing the target will force a retry, but changing the metadata will not. If uploading the metadata failed, then changing the target will cause the file to be uploaded to the new location and the metadata will be uploaded there. Changing just the metadata, and not the target, in this case will result in Quick Upload attempting to upload the new metadata.
As well, users may hit the Retry button for any failed upload. This will put the file or the metadata in the queue and Quick Upload will try up to two additional times before again considering the upload failed.
Users may also select Stop for files or metadata which have not yet been uploaded. This is generally done not to address upload errors, but to allow users to change their minds about the target or metadata. Resume may be selected for any stopped files.
2. Logging
Logging is enabled in a file called bu.ver. When Quick Upload is installed, the bu.ver file is placed in the same directory as Quick Upload. It works quite similar to the oe.ver file used by the Go-Between. The values that may be specified in this file are:
- log_path - specifies the directory where the log file will be placed
- log_communication - 0 or 1, indicating if communication with the server is logged
- log_function_calls - 0 or 1, indicating if internal function calls are logged
- hide_passwords - 0 or 1, indicating if passwords are omitted from the log files
- supress_version_warning - 0 or 1, indicating if the warning message related to checking the Quick Upload and server have matching versions.
Users may edit the bu.ver if they wish to change the manner in which logging is performed. By default, logging will be enabled. If log_path is not defined, log files will be written to a directory called /log, which will be a sub-directory of the directory in which Quick Upload is installed.
Sample bu.ver file:
logging=1
log_communication=1
log_function_calls=1
hide_passwords=1
3. Reporting Problems
Most problems can be addressed by correcting errors at the server though a web browser. For example, a user may select to upload a file to a certain location, but another user may, before it is uploaded, delete or move that container. Fixing this, then, may require selecting a different target or changing the site back to its original organization.
The Set Properties dialog has a field at the bottom where all errors related to uploading the file or the metadata are displayed. This is often useful for identifying problems.
In the event of severe application errors, the Quick Upload application uses a utility it includes called BugTrap, which sends an error report by email to the OpenEngagement development team, who can use this information to correct any bugs. Users may select to not send the error report, though no sensitive data is sent. The contents of the files being uploaded, for example, are not sent.
Users are encouraged to also email us a log file if possible. See the section on logging for information about this. OpenEngagement can be emailed at admin@openengagement.com.
Users may also post any bugs or feature requests on our issue tracker, also on this web site.