in reply to Portably transforming a string to a valid filename

I'm not at all up on "encryption" algorithms, but it seems that what you want is a two-way algorithm that (a) isn't computationally expensive and (b) yields 'encrypted' data that's encoded in filesystem-friendly strings. It's the last that's got me stumped. Just that thinking "encryption" might give you some ideas for other searches.

How about an alternate scheme: instead of backing things up one file to a node, write out all the user's nodes into a standard format (XML, anybody?): 

<node>
 <title>How I learned to stop worrying and Love the NodeReaper</title>
 <time>December 31, 2001 : 24:00:00</time>
 <node_content>He got rid of those nasty nodes.  nuff said</node_conte
+nt>
</node>

[download]

Then gzip the whole thing, and there's your backup.

Philosophy can be made out of anything. Or less -- Jerry A. Fodor

Replies are listed 'Best First'.
Re: Re: Portably transforming a string to a valid filename
by eg (Friar) on Feb 20, 2001 at 02:53 UTC

    You can just use pack to uuencode your file-name strings to be extremely file-system friendly (or, you can install linux or freebsd or something and get a friendlier file-system :)

    To the original poster: don't do this. It's a waste of bandwidth (as well as a serious copyright violation.) Just /msg nate and ask him if he'll send you a copy of the database. He (probably) won't and you can move on to another project.

    update ignore the last paragraph -- my misunderstanding. thought you planned on backing up the *entire* database. apologies all around.

    update2 too bad E2's displaytype=xml doesn't show softlinks as well.

[reply]
      I think you misunderstand my intent; it's for a user to back up their own writeups. In fact, it won't work on another user unless you had their login and password, as it taps into E2's XML writeup displaytype, which requires that one be logged in as the user whose writeups are to be viewed.
[reply]

        Let me stump again for my kind of solution (XML or no XML; flat file would work just as well). It would be easy enough to write a script that goes through the generated files and builds up a list of titles, or that spits out the node corresponding to a given title (this is beginning to sound like fun, actually!).

        I don't see that there's a significant benefit to storing each node in its own file anyway. Or perhaps you can explain why you want to do it this way?

        Philosophy can be made out of anything. Or less -- Jerry A. Fodor

[reply]

In Section Seekers of Perl Wisdom