![]() |
SyncDiscsSupplementary information |
Date and time stamps on RISC OS are simple. There is only one date and time stamp associated with a file, corresponding to when the file was last modified (saved). It is therefore simple to compare two date and time stamps to find which is the newer, or whether they are the same.
Some other OSs have more than one date/time stamp associated with a file. These may include some or all of:
When using another OS to backup files, time stamps can become a problem. The following description relates to one of my systems.
I have a type NSLU2 NAS (network attached storage device), which runs a 'mini' unix OS. I access it using LanMan98. If you copy some files and/or directories to it and then inspect the date stamps of the copied files in a filer window using full info mode, you see that the date/time stamps correspond to the time of the copy, and not when the file was last modified. The date/time stamps therefore differ between RISC OS and the external device.
Running a SyncDiscs compare will report that all the files on the NAS (secondary directory) are newer than those in the primary directory. Very confusing! However, running a synchronisation at a later date will not copy any files unless their date/time stamp is later than the time the file was copied to the NAS, i.e. it is still the case that only changed files will be copied. There is one complicating factor. You must ensure that the following options are UNTICKED.
If either of these are ticked then there will occur lots of unnecessary copy operations.
Experiences with other devices and operating systems may be very different. It would be wise to check any devices you are using for backups to see how the time stamp behaves in each case, and set the synchronisation options accordingly.
The following was taken from a MicroSoft support page. It shows there can be inconsistencies even on the same OS when different filing systems are in use. The actual details apply to the Windows OS and NOT to RISC OS - they are included here to demonstrate the minefield of file time/date stamps when mixing filing systems.
A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC). The system records file times when applications create, access, and write to files.
The NTFS file system stores time values in UTC format, so they are not affected by changes in time zone or daylight saving time. The FAT file system stores time values based on the local time of the computer. For example, a file that is saved at 3:00pm PST in Washington is seen as 6:00pm EST in New York on an NTFS volume, but it is seen as 3:00pm EST in New York on a FAT volume.
Timestamps are updated at various times and for various reasons. The only guarantee about a file timestamp is that the file time is correctly reflected when the handle that makes the change is closed.
Not all file systems can record creation and last access times, and not all file systems record them in the same manner. For example, the resolution of create time on FAT is 10 milliseconds, while write time has a resolution of 2 seconds and access time has a resolution of 1 day, so it is really the access date. The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.
A syncjob file is created when the menu button to the right of the Save button in the main control window is used to raise a Save as dialogue, and the file is saved, either by dragging the file icon to a Filer window, or by entering the full path and pressing <Return> or clicking on OK.
The file will contain a complete copy of every setting (as in the main control window and the additional settings window) as pertaining at the time the file is created. These settings will be used to start or queue a synchronisation when the file is subsequently run.
In order for syncjob files to be recognised and acted on correctly, then, if SyncDiscs has not already been run, SyncDiscs must have been 'seen' by the filer. This occurs when the directory containing SyncDiscs is first opened by the filer, or by adding SyncDiscs to Configure>Boot>Look at so its !Boot file is run when the machine is booted.
The alarm edit window will open (shown below). If you do not yet have any alarms entered, the alarm edit window will open immediately when you select Alarms... from the iconbar menu.
The screen shots above were taken using !Alarm version 2.79 (RISC OS 5)
The above screen shot was taken using !Organizer version 2.06.
Create a new obey file in your favourite text editor. Type in Filer_run followed by a space. Leave the caret where it is and, while holding down Shift, drag in the syncjob file you wish to include and then press <Enter>. Holding down the Shift key means that the file path of the dragged file is entered into the file, rather than the contents of the file. Repeat for other files as required. The obey file may now look something like this.
Now save the file in a suitable location. Make sure it is filetyped as an obey file. Double clicking on its icon will run it, the effect being to load all the jobs into the SyncDiscs queue and run them. You could also set up a task alarm for it in the same way as described above. When the file is run by the alarm application, the jobs will be queued in SyncDiscs and processed in turn.
These pages are best viewed in a CSS compliant browser. For RISC OS, Netsurf would be the browser of choice.
SyncDiscs is © 2012, Chris Johnson and David Pilling
Email:chris@chris-johnson.org.uk
This document last modified on 5th April 2014