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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Rsyncrypto-devel mailing list Rsyncrypto-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
