sneaker_net_sync
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
sneaker_net_sync [2013/05/21 23:48] – created stephen | sneaker_net_sync [2017/01/01 20:05] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 3: | Line 3: | ||
====== | ====== | ||
+ | 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, | ||
+ | |||
+ | ==== Why would anyone use a sneaker net? ==== | ||
+ | |||
+ | * 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. | ||
+ | |||
+ | ===== How does it work? ===== | ||
+ | |||
+ | **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. | ||
+ | |||
+ | ==== 1. Create the index file (secondary 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 '' | ||
+ | |||
+ | The '' | ||
+ | |||
+ | The '' | ||
+ | |||
+ | The '' | ||
+ | |||
+ | Click '' | ||
+ | |||
+ | ==== 2. Sneaker net the index file to the master computer ==== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | ==== 3. Create the delta file (master computer) ==== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | The '' | ||
+ | |||
+ | The '' | ||
+ | |||
+ | The '' | ||
+ | |||
+ | Click '' | ||
+ | |||
+ | === Advanced Options === | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | If the '' | ||
+ | |||
+ | The '' | ||
+ | |||
+ | 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, | ||
+ | |||
+ | TODO: Rename this option to '' | ||
+ | |||
+ | The '' | ||
+ | |||
+ | ==== 4. Sneaker net the delta file to the secondary computer ==== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | ==== 5. Apply the delta file (secondary computer) ==== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | The '' | ||
+ | |||
+ | The '' | ||
+ | |||
+ | If the '' | ||
+ | |||
+ | Click '' | ||
+ | |||
+ | ===== Edge Cases ===== | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | If this possibility is unacceptable, | ||
+ | |||
+ | ===== Daylight Saving Issues ===== | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ==== The Problem ==== | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ==== The Cause ==== | ||
+ | |||
+ | 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 Workaround ==== | ||
+ | |||
+ | There is no practical way of ' | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | '' | ||
+ | |||
+ | Only use this option if Sneaker Net Sync is not affected by the daylight saving issue, or there a concern about the [[# | ||
+ | |||
+ | '' | ||
+ | |||
+ | Use this option if whether or not the modified dates remain synced is completely unimportant. | ||
+ | |||
+ | '' | ||
+ | |||
+ | Use this option if it is important that the modified date remain synced as much as possible. | ||
+ | |||
+ | '' | ||
+ | |||
+ | Use this option if it is important that the modified dates // | ||
+ | |||
+ | '' | ||
+ | |||
+ | ==== The Daylight Saving Edge Case ==== | ||
+ | |||
+ | If the Time Zone Options is set to anything other than '' | ||
+ | |||
+ | - A file is modified on the master computer. | ||
+ | - Sneaker Net Sync creates a delta file. | ||
+ | - 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 '' |
sneaker_net_sync.1369180092.txt.gz · Last modified: 2017/01/01 19:52 (external edit)