Incompatible changes in the next version of rsyncrypto

[Shachar S. <sh...@sh...>]

Hi all,

This is a heads up, as well as a chance for you to give some input, 
about two incompatible changes I'm planning for the next version of 
rsyncrypto.

The first change has to do with the "--file-list" option, that allows 
giving a list of files to be processed. At the moment, --file-list is a 
parameter less option, and it merely changes the meaning of the first 
argument from being the actual source file, to being a list of files 
that are used as source. If the first argument is "-", this means that 
the list is read from standard input.

The problem begins when the --name-encrypt option is used for either 
decryption or encryption. With this option, the directory in relation to 
which the names are interpreted is crucial. The current scheme leave no 
other option than "the current directory". However, asking the client to 
change the current directory as part of the program's arguments seems a 
bit of an onus requirement.

The change I am planning is to have --file-list accept a single 
parameter saying "which file to use", with "-" meaning stdin as before. 
The first argument to rsyncrypto will now be the directory in relation 
to which the names given in the file list are interpreted.


The second change is only relevant to Windows. I want to make rsyncrypto 
a Unicode built application. On the pluses, this means rsyncrypto will 
be able to handle any file name, no matter what the locale is. However, 
this does require that rsyncrypto use a different format in the filemap 
file (for name encryption) than what is used today. The obvious solution 
is to store this in UTF-16 (which is what Windows uses internally for 
Unicode applications). I see two major problems with this option. The 
first is that this throws out of the window any chance of accessing this 
file from a Unix machine. The second is that there are not that many 
UTF-16 capable editors out there.

A better solution, as far as I'm concerned, is to use UTF-8. This is a 
fairly standard format, and is easily readable by Unix machine by merely 
setting LC_CTYPE to en_US.utf-8 (or any such locale). It is also the 
default locale for most modern Linux distributions. There is just one 
problem - it is very difficult to say, by merely looking at a file, 
whether it is ANSI (the Windows term for non-Unicode) encoded or whether 
it is encoded in UTF-8. This means that upgrade to a new version of 
rsyncrypto would require a manual conversion of the filemap file (I 
will, of course, provide a tool to do that).

I should just point out that this will only affect users of rsyncrypto 
for Windows outside of the USA. If all you use is ASCII for your files, 
then UTF-8 and ANSI produce the same encoding, and you will not see the 
problem.


Another solution, which I am leaning toward, is to add a version number 
to the filemap file. This will allow new versions of rsyncrypto to read 
old version's filemap and use it (but will totally destroy any chance of 
working the other way).

Your input is greatly appreciated.

Thanks,
Shachar