-->
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.
To generate the package list on the GNOME version of Linux Mint, I used the Backup Tool. It simply was a matter of using the Backup Software Selection button and telling it where to put the file that it generates. Alternatively, dpkg can be used from the command line like this:
sudo dpkg --get-selections > /backup/installed-software.txt
After transferring the file to the machine with Linux Mint Debian Edition, I tried using the Backup Tool on there too. However, using the Restore Software Selection button and loading the required only produced an irrecoverable error. Therefore, I set to looking around the web and found a command line approach that did the job for me.
The first step is to load the software selection using dpkg by issuing this command (it didn’t matter that the file wasn’t made using the dpkg command though I suspect that’s what the Linux Mint Backup Tool was doing that behind the scenes):
sudo dpkg --set-selections < /backup/installed-software.txt
Then, I started dselect and chose the installation option from the menu that appeared. First time around, it fell over but trying again was enough to complete the job. Packages available to the vanilla variant of Linux Mint but not found in the LMDE repositories were overlooked as I had hoped and installation of the extra packages had no impact on system stability either.
sudo dselect
Apparently, there is an alternative to using dselect that is based on the much used apt-get command but I didn’t make use of it so cannot say more:
sudo apt-get dselect-upgrade
All that I can say is that the dpkg/dselect combination did what I wanted so I’ll keep them in mind if ever need to synchronise software selections between two Debian-based distributions in the future again. The standard edition of Linux Mint may be based on Ubuntu rather than Debian but Ubuntu is itself based on Debian so the description holds here.