Sneaker Net:

To transfer files or data by physically moving media (typically USB drives or external hard drives) from one computer to another. Sneaker refers to a type of footwear sometimes associated with the stereotypically causal IT professional.

Sneaker Net Sync is an application that synchronises files between two computers without using a computer network connection. No need to figure out which files or directories have been changed, added or deleted - Sneaker Net Sync will do that out for you and make the required changes. Sneaker Net Sync is great for creating off-site backups.

Note: Sneaker Net Sync only does one-way synchronisation, meaning that it makes changes to the files on one computer to make them exactly match the files on the other computer. Technically, this would be better described as a mirror, but somehow 'sneaker net mirror' doesn't quite roll off the tongue as easily.

• Either one or both of the computers may not be connected to a computer network.
• The changed files may be very large. Sneaker nets using a USB drive or an external hard drive can often have a much higher bandwidth than a computer network.
• The contents of the changed files may be sensitive. Files on a physical USB drive are often much easier to secure and keep private than sending them over a computer network.
• It may be inappropriate to send certain types of files over a particular computer network. For example, sending personal files over a corporate computer network may violate the usage policy.

Master Computer: This is the computer that contains the source files. These files are only ever read and are not modified.

Secondary Computer: This is the computer that contains the files that will be changed to match the files on the master computer.

In this example, we are going to create a backup of our pictures. We start by going to our secondary computer.

The drop down at the top of the window and the Save and Delete buttons allow all of the settings to be saved for later use or deleted when they are no longer required.

The Secondary Source in this case is our backup directory. The directory must exist, but it can be empty.

The Index File is the file that contains an index of all of the files in the Secondary Source. This is used to identify changes between the files on the master and secondary computers. This file must be transferred to the master computer. In this case, D: is the USB drive that we are going to sneaker net to the master computer.

The Generate hash values will add a hash value for each file into the index file. This will significantly increase the amount of processing time, both at this stage and later when the delta file is created.

Click Start to create the index file.

The Master Source in this case is the directory where the files we want backed up are. These files are only ever read and are not modified.

The Index File is the file created in step 1.

The Delta File is the file that will be created. It will contain all of the modified and new files and details about how to change the files on the secondary computer to exactly match the master computer. This file must be transferred to the secondary computer. In this case, D: is the USB drive that we are going to sneaker net to the secondary computer.

Click Start to create the delta file.

If the Use Temp Dir option is checked, the delta file will be created in the Windows temporary directory and then moved to the final location. This is much faster if the final delta file location is on a USB drive or an external hard drive, but will be slightly slower if the delta file is on the local hard drive.

The Limit Size can be used to set the maximum size of the delta. Most USB drives are FAT32, which means that the maximum file size they can support is 4GB. In this case, the Limit Size should be set to 3.9 GB. If there are more than 3.9 GB of files to sync, the extra ones are ignored. This means that the files on the secondary computer will not be fully in sync first time around, but the sync process can be repeated until they 'catch up'.

Note that the delta file is compressed and the size limit is applied before the compression is done. This is because there is no easy way (other than actually doing the compression) to know how much a file will be compressed and therefore how many files can be added without the final file going over the size limit. By limiting the size before compression, we can at least ensure that the final file will always be less than the limit.

TODO: Rename this option to Size Limit.

The Time Zone Options and Time Difference settings are used to rectify daylight saving issues that can sometimes occur. See Daylight Saving Issues for more details.

The Secondary Source in this case is our backup directory. It should be the same as what was used in step 1.

The Delta File is the file created in step 3.

If the Re-index is checked, the index file is recreated (using the settings on the 'Create Index' tab) after the delta has been applied. This allows step 1 to be skipped when the sync process is repeated.

Click Start to apply the delta file.

There is a possible situation that would prevent Sneaker Net Sync from detecting that a file has changed. When a computer program modifies the contents of a file the operating system (Windows) automatically updates the modified date of the file. However, a program can also directly set the modified date to anything. A program could theoretically read the modified date of a file, change the contents of the it and then set the modified date back to its original value. This would be very strange behaviour indeed. If the length of the file did not change, Sneaker Net Sync would not detect the change and would not ever re-sync the file.

This edge case is very unlikely to happen, but if it was a concern, hash values could be used. This would prevent the edge case, but using hash values dramatically slows down the indexing and delta creation process.

Well… almost. Hash values do not fully eliminate the edge case. While it is incredibly unlikely that two files with different content would have the same hash value, it is technically possible. Sneaker Net Sync uses a 128-bit hash, which means that there are approximately 3.402 × 10³⁸ possible unique hash values. Assuming truly random distribution, the chances of two files having the same hash value is about the same as throwing three pins at the Earth from space such that they land at some random point on the Earth's surface, and all three land within 1 mm of each other (the Earth's surface area is approximately 5.1 × 10²⁰mm²).

If this possibility is unacceptable, the only option would be to fully recopy all the files every time a re-sync is done. Even this would not absolutely and completely guarantee that the files are synced - there could be read or write errors while copying the files to and from the transport media.

Obviously, if both the master and secondary computers are set to a time zone that does not have daylight saving, they will not be affected by this issue. If both computers are Windows 7+ and the file systems are NTFS, they should also not be affected. Otherwise, they might be affected.

After changing to daylight saving time or back to standard time, Sneaker Net Sync may incorrectly determine that all the files have been modified and attempt to resync them all.

Sneaker Net Sync relies on the name, length, modified date and hash (if generated) of a file to determine if it has been modified, added or deleted. It turns out that there are two issues that can make the modified date unreliable:

• On FAT32 file systems, the modified date is recorded using the local system date and no time zone offset is stored. When a file is moved to another computer it is no longer possible to exactly determine what the real modified date is. On NTFS file systems, the modified date is stored as UTC. It will always be correct, even if the host system changes its time zone.
• When Windows XP converts the modified date of a file between UTC time and local time it adds or subtracts the current time zone offset. This method does not deal with daylight saving time correctly. The correct method is to add or subtract the time zone offset that was in use when the file was modified. Windows 7 and above uses the correct method.

Unfortunately, the bottom line is that file modified dates can not always be reliably compared between different systems.

There is no practical way of 'fixing' the daylight saving issue. The best that can be done is a workaround. On the Create Delta tab, select the Advance Option button:

None: Nothing special is done. All files will be resynced when going into daylight saving time and back to standard time. Typically, this will take a long time and will create a huge delta file and/or may require multiple resyncs to 'catch up'. Once the files are resynced, the file modified dates will match between the master and secondary computers.

Only use this option if Sneaker Net Sync is not affected by the daylight saving issue, or there a concern about the edge case.

Ignore time differences: If the name, file size and hash (if used) match and the modified date is different by the amount specified by the Time Difference setting (+/- 3 seconds) the difference will be ignored and the file will be considered to be 'in sync'. Nothing special will happen when going into daylight saving time or back to standard time. Files added or modified during daylight saving time will have modified dates that do not match the master computer's files. These files will also have modified dates that are incorrect relative to the files that were not modified during daylight saving time. The incorrect modified dates will never resync.

Use this option if whether or not the modified dates remain synced is completely unimportant.

Correct time differences: If the name, file size and hash (if used) match and the modified date is different by the amount specified by the Time Difference setting (+/- 3 seconds) the modified will be resynced, but not the contents of the file. When going into daylight saving time or back to standard time, all the files will have their modified resynced. Typically, this does not take too long and does not result in a very large delta file. Once the modified dates are resynced, they will remain synced.

Use this option if it is important that the modified date remain synced as much as possible.

Correct time … ignore time…: When it is daylight saving time, modified dates are ignored as described above. When it is standard time, modified dates corrected as described above. When going into daylight saving time, nothing special will happen. When going back to standard time, incorrect modified dates will be resynced. This will only affect files that were added or updated during the daylight saving period so will typically be much faster than the Correct time differences option. Modified dates will be synced during standard time. During daylight saving time, the modified dates of new or updated files will be correct.

Use this option if it is important that the modified dates eventually sync up.

Time Difference: The amount of time that should be ignored or corrected.

If the Time Zone Options is set to anything other than None, there is a known edge case that could potentially cause Sneaker Net Sync to fail recognise that a file has changed - although the chances of this occurring are very remote. It would have to happen like this:

1. A file is modified on the master computer.
2. Sneaker Net Sync creates a delta file.
3. The same file is modified, without changing its length, one hour (+/- 3 seconds) after it was originally modified.

Because the modification date of the file will have increased by one hour and the length remained the same, Sneaker Net Sync will either ignore the change or update the modified date without updating the contents.

If this edge case is a concern, the Time Zone Options can be set to None or hash values can be used.