Re-3: Encrypting a Filename

Re SSH: Since I don't have that, I'm really looking for a self-contained solution. This script backs up to another part of the file system, which can be a different spindle or could be a "backup buddy" over the network, but it doesn't require a network. I will check it out, though.

As for efficiency, that's not my worry. I'm more concerned with file name limitations of the receiving system. Burn to a standard CDR for example, limits the length and character set. I can punt on that if I just say "ZIP the files, then burn that" because ZIP doesn't have a length limit and pretty much likes any 8-bit character string as a name. However, what if your source is case-sensitive and the dest is case sensitive? In my situation at home, the source is NTFS with full Unicode names, but the dest is FAT32.

So, I'm thinking of URL-encoding the names and sticking to a small destination character repertoire. Preserves case. BUT, what about case clashing if the dest is case-insensitive? I suppose I need to encode that too, and assume the dest is case smashing!!

Any thoughts, on any of that? Don't you hate contradictory requirements?

—John

Comment on Re-3: Encrypting a Filename

Replies are listed 'Best First'.
Re: Re-3: Encrypting a Filename by marcink (Monk) on Jun 15, 2001 at 03:47 UTC
I'm more concerned with file name limitations of the receiving system. One more suggestion, then: calculate the encrypted file name with some kind of digesting algorithm (with numeric suffix to make it unique), while encrypting the original name together with file contents (by prepending or appending it to the original file)? Pro: you can make the filename generator use very small character set. Cons: 1) file name decoding requires more work (and the encrypted version is not sufficient), 2) finding encrypted file might require proximity searching, -mk	[reply]
Re-6: Encrypting a Filename by John M. Dlugosz (Monsignor) on Jun 15, 2001 at 05:24 UTC
If I make the source=>dest one-way, such as by truncating, I can store the real filename inside the file. That provides the other way. However, next time it goes the first way, it may not be unique, if suffixes are added to disambiguate. It may have to check several candidates to see which matches. Perhaps that will be rare, especially if I set the limits to match the real destination filesystem (so it doesn't fold more than it has to). Not as elegant as 1:1, but probably not over-burdened. Hmm, but it would mean it always has to open the file to check the real name, not just compare dates to see if the backup needs freshening. —John	[reply]