Adventures & experiences in contemporary technology
With a growing collection of photographic images, I often find myself making backups of files using copy commands and the data volumes are such that I don’t want to keep copying the same files over and over again so incremental file transfers are what I need. So commands like the following often get issued from a Linux command line:
cp -pruv [source] [destination]
Because this is in Linux, it the bash shell that I use so the switches may not apply to others like ssh, fish or ksh. For my case, p preserves file properties such as its time and date and the cp command does not do this always so it needs adding. The r switch is useful because the copy then in recursive so only a directory needs to specified as the source and the destination needs to be one level up from a folder with the same name there so as to avoid file duplication. It is the u switch that makes the file copy incremental and the v one issues messages to the shell that show how the copying is going. Seeing a file name issued by the latter does tell you how much more needs to be copied and that the files are going where they should.
What inspired this post though is my need to do the same in a Windows session and issuing xcopy commands will achieve the same end. Here are two that will do the needful:
xcopy [source] [destination] /d /s
xcopy [source] [destination] /d /e
In both cases, it is the d switch that ensures that the copy is incremental and you can add a date too, with a colon between it and the /d, if you see fit. The s switch copies only directories that contain files while the e one copies even empty directories. Using the d switch without either of those did not trigger any copying action when I tried so I reckon that you cannot do without either of them. By default, both of these commands issue output to the command line so you can keep an eye on what is happening and this especially is useful when ensuring that files are going to the right destination because the behaviour differs from that of the bash shell in Linux.
When I started into the world of computing at university, 200-300 MB hard drives were the norm for PC’s. My own first PC had what was then thought a sizable 1.6 GB disk and things have increased in size since then. I now have access to several hundred gigabytes of storage at home and we are now seeing 1TB offerings for the PC market.
Terabyte storage has been the preserve of the server market but given the disk sizes that are available now, even larger units are needed to describe the sizes of data volumes, ones that I haven’t seen before. So here goes:
Unit | Number of bytes | Number of bytes | Number of bytes |
petabyte | 1024 TB | 2**50 | 10**15 |
exabyte | 1024 PB | 2**60 | 10**18 |
zettabyte | 1024 EB | 2**70 | 10**21 |
yottabyte | 1024 ZB | 2**80 | 10**24 |
* Binary measurements are used by operating systems like Windows while decimal ones are used by hard drive manufacturers
I know that the above strays into the realms of esoterica but, with the way that things have been going, we may be talking about petabytes before very long. As it so happens, HP recently mentioned zettabytes when talking about its range of UNIX servers and I needed to go looking up what it meant…