Re: [Gnu-arch-users] Increasing the filename space (Or: begging for trouble?)

[Christian Thäter]

> Until arch starts using UTF-8 for filenames internally, the hard-coded
> 7-bit invalid_characters test must remain.
> 
> The hard-coded "spaces and glob characters" test can go away, but
> should remain as the default and be supplemented by a =tagging-method
> override.

ok, note that we could keep 7bit forever and escape utf-8. I dont know if that 
really makes sense, just an idea.


> That's false.... but our messages are probably crossing on the list.
> I've explained how to do it.

Thats almost like i thought, convert or barf.


> Please catch up with my recent messages in this thread.

You make the game, it doesn't really matter how the metadata is encoded as long 
it is well defined. My suggestion might give a slight performance benefit and 
native readable metadata, ymmv.

about filename hinting:
that was really meant as *hint* only, just that tree-lint can give a warning 
like "you will never get this on FAT or iso9660" or "foo.c and FOO.C will 
conflict on FAT"

>     [merge plan]
>     >         4) a bunch of single patches which make additional things work
>     >            escaped logs/inventory printout and so on
>     >         5) a 'tla unescape' and 'tla escape' command as tool for 
> scripts        6) hackerlab escaping performance improvements
>     >            (perfect hashing, AVL-Tree lookup etc)
> 
> Please elaborate on what you mean by 4 and 6, and why 5 is needed.
4)
some of the current commands print formatted data like file/patch lists, this 
lists might be '--escaped' if one intends to process them with a script

5)
tla escape 'foo bar' -> 'foo\40bar'
tla unescape 'foo\40bar' -> 'foo bar'
People told me that some external utilities parse tla metadata, i didnt 
checked, but if they do they need to be escaping aware and need to be updated. 
This commands are just used as authorative escaping engine for such scripts to 
ease the maintainance.

6)
the escaping engine is table driven, by default it currently uses a brute-force 
search which is somewhere at O(N*M). The lookup strategy can be changed. For 
static defined tables like in tla, it would be nice to create a pefect hash at 
compiletime to make it much faster. For dynamic build/loaded escaping tables an 
AVL tree might be the choice (easy insert, no deletes). Note: I consider this 
parts as fun excercise with some real value, but it has no priority.


> Also: have you been using and do your patches include updates to both
> the tests run by `make test' and the `changeset-tests'?   The latter
> is absolutely critical.

Yes! Do you want a forked of testsuite (which will slow the test down)
or would it be enough if the current tests are changed to contain spaces in 
filenames (i prefer that, since it has no other side effect and doesn't make it 
twice as slow)

 
> Documentation updates for the new =tagging-method option are also
> important.

I first focus on the escaping engine, for now there is nothing changed to the 
=tagging-method. But where documentation must be updated i will do it.


> I discourage that.  In particular: it does very little to advance my
> confidence for merging;  similar attempts in the past have left users
> with corrupt archives;  you seem to be trying to be sneaky.

Well if someone crashes his production archives with a "please test this alpha 
release" he can't blame me, or? 

Well, i will just send you early merge requests.


        Christian