Tag Archives: upload

Version 1.0.41 – Added Detail to Explain FTP Checksum non-Match

Posted on by

FTP Checksum validation was improved in Version 1.0.36; there was a typo, and really very little explanation.

Although there’s not a whole lot more detail, the reason for a Checksum Unknown was described with a hint as to how to use this capability in future.

As a note: the checksum file format intentionally matches the output of the “md5sum” or “md5” command line tools to which other tools are compatible. Most checksum tools are compatible.

Of note: using vict.jar to upload automatically produces checksum files for validation.

For example:

vict.bat -U (server) -u file1 -u file2 -u file3

or:

java -jar vict.jar -U (server) -u file1 -u file2 -u file3

This simple functionality creates a checksum, sends it to the server, uploads the file(s), and confirms checksum with the server (where supported).

The Server-side FTP check functionality that alerts us to uploads automatically uses the checksum file to validate accuracy of the upload.

I cannot see how to make this easier.

Revision 613 – fctransfers Gives us SFTP Uploads

Posted on by

In rev 605, the code for uploads was completely dependent on the code brought in with fctransfer.jar’s convenience library.

This revision evolves that change: all uploads are delegated to the fctransfer project, which means we get SFTP uploads for free:

Upload methods are now:

  • FTP: java -jar vict.jar -U ftp://scott:tiger@ftp.example.com/path/ -u file1 -u file2
  • SFTP: java -jar vict.jar -U sftp://scott:tiger@ftp.example.com/path/ -u file1 -u file2

Notice the similarity? That’s intentional.

Of course, both upload methods send a checksum including a notify element.

There remains some oddity in the commons-net-ssh used; I may need to swap out the underlying ssh to sshj or such.

Revision 584 – User-Documentation in .sum Files

Posted on by

The checksum files sent by an upload really assume that the recipient knows something about checksums. It’s also very difficult to discover what these files are used for lacking the ability to google (whether one arrives at “RFC-1321” or not)

In order to alleviate that assumption, I added some documentation to the actual .sum checksum files provided during an upload. This still requires that a recipient opens the file, but it’s a useful step forward until I can reach through a screen and click the user’s mouse for him.

Revision 582 – Swapped .sum Checksum File to be Available Before the Upload

Posted on by

One part of the Client Tool makes uploads easier if you’re willing to type a commandline; and if you’re not, a batch file is present to reduce that obstacle (but still no GUI).

In order to reduce the doubtful situation of having an upload without confirmation (for example, in cases where an aborted upload looks just like a completed upload: no checksum either way), the upload functionality now sends the checksum before the actual file. I swapped the uploading of the payload file (-u) and the .sum checksum so that the ~.sum file is present before the payload; in truncated/aborted/chopped uploads, this provides a checksum to validate and prove an inaccurate upload rather than assume meaning from a missing .sum file. Aborted/truncated uploads will still fail to validate against the checksum so look the same as any corrupted upload: incorrect. In either case, the reaction is “ask for a re-upload”, so the reaction to a checksum mismatch remains an immediate re-upload.

Revision 580 – Added VIUpload Script

Posted on by

To avoid recurring errors uploading, I added a convenience script “viupload.bat”; it’s used as follows:

  1. copy it to the host from which uploads shall be pushed
    • you’ll need VIUPLOAD.BAT
    • you’ll need VICT.JAR
    • of course, even though this works in any subdirectory, we recommend that these be stored in the UnSupported subdirectory
    • these scripts are not supported by the American Society for Prevention of Cruelty to Animals, nor any other entity, nor have we ever claimed them to be
  2. edit the following variables:
    1. UPLOAD_USER should be set to your username
    2. UPLOAD_PASS should be set to your password (plaintext, this is for convenience not security)
    3. UPLOAD_SUB can remain “ftp” or be set to a region (other regions REM’d out for example)
    4. UPLOAD_PATH should be empty or set to a preexisting subdirectory on the server to which uploads should be stored
  3. run it with a list of files; for example VIUPLOAD PortalLogs.zip HOSTNAME.err backup-2013-09-03-15-02.zip