On Sat, Jul 29, 2006, EV wrote:
> > It is the only way to *guarantee* reversibility.
>
> I know, but non-reversibility is not going to set fire to your
> house ;) - and some people (me ;) may want to take the risk...
Okay. I guess it is a personal thing. I would always prefer to have an
ugly pathname that I know will always work than a pretty one which
will fail from time to time. I was particularly put off by the fact that
when I first tried lkarmafs using the recommended options I found that
about 10% of the files were unreadable.
> At some point I may like to see the '/' as just '\' (not '\\' !)
> as this character is very unlikly to appear in titles, artists,
> etc... So I'd like some possibility of choice. Again, your new
> idea may change my mind...
That is not possible to do in a safe way if '\' is also being used as
the escaping character. You can either pick a different character to
use for escaping (which also needs to be rare, such as '$', '{' or '}')
or pick a different character for '/'.
I think that the '/' character is one area where users should not even
get the option of breaking the filesystem. They should be allowed to
change the character used as a replacement for '/' but should not be
able to prevent it from being replaced. This can easily be achieved by
appending '/' and '$' (or similar) to the ends of editPathStr1 and
editPathStr2 respectively.
> > Or if you would rather have the potentially dangerous
> > tr-editing back then I'll hard-code the '/' character
> > translation. I think that this is the only character that
> > absolutely has to be changed?
>
> I'd rather like to allow both (alternative, to make things
> simpler) edditing methods. By default '/' could be changed for
> '\' and the (unlikely) original ones additionally escaped ('\\')
> Is this O.K. with you?
I don't care what character gets used as either the escape
character or the replacement for '/' provided that they are both rare
and different from one another.
> > One version appears to get a '.' and the other doesn't. This
> > would only be noticed if two filenames with the same pathname
> > but different encodings were used. If the rep list was
> > null-terminated instead of terminated by '\n' then the aux
> > string becomes redundant and can be removed altogether.
>
> I'll revise the code this evening, thanks. Can you provide a
> specific example where the current method fails?
My guess is that it is meant to prevent to files with the same name from
showing up in the same directory? In that case it *always* fails for me
when it comes to tune files. (Not different encodings as mistakenly
mentioned above).
eg. (using vanilla lkarmafs-0.1.7)
$ ls /mnt/karma/tune/A-Ha/Hunting\ High\ And\ Low/
Take On Me.ogg Take On Me.ogg Take On Me.ogg Take On Me.ogg
Keith.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-karma-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-karma-devel
