Problem in KoStore in opening files

[David Faure]

On Friday 10 August 2012 12:24:02 Inge Wallin wrote:
> On Friday, August 10, 2012 12:15:37 mojtaba shahi Senobari wrote:
> > Hi all
> > 
> > I am working on filter and in one part of my work i needed to open an
> > image
> > and extract it with KoStore and i got error.
> > 
> > the image name that i wanted to open (it was an LO doc ) was :
> > Pictures/100000000000023A0000023A7EEDCDE3.jpg
> > and in my debug output i got this : "can not to open
> > Pictures/part100000000000023A0000023A7EEDCDE3.jpg/maindoc.xml"
> > 
> > Then i did some research and found this method :
> > KoStorePrivate::expandEncodedPath(...)
> > 
> > when you want to open a file in KoStore,  at open method it goes to
> > toExternalNaming(..) method and in this method ( toExternalNaming ) it
> > returns
> > this   " return expandEncodedPath (..)" .
> > 
> > and in expandEncodedPath()  you can see these comments:
> > 
> > // Now process the filename. If the first character is numeric, we have
> > // a main document.
> > 
> > What should i do? is there some thing wrong with this method or i should
> > do
> > some thing for opening files such as these like these files.
> > 
> > moji
> 
> As I said on irc, this is obviously a bug (or at least a faulty design). We
> cannot have a store class that cannot open a perfectly valid file just
> because the filename starts with a figure. This has to be fixed.
> 
> The tricky part is that there may be other code that depends on this
> behaviour. Can we have a comment from the old guard regarding this (David)?


For reasons that I cannot remember anymore, KoStore converts a naming scheme 
to another:

     * tar:/0 is saved as part0/maindoc.xml
     * tar:/0/1 is saved as part0/part1/maindoc.xml
     * tar:/0/1/pictures/picture0.png is saved as 
part0/part1/pictures/picture0.png

This, however, looks very much like the old native format, not the 
OpenDocument format.

Are there finally again some filters that support the old native formats?

In any case, the right solution is to disable the use of 
KoStorePrivate::expandEncodedPath. This possibility already exists:

KoStore::disallowNameExpansion() is the method to call in order to fix this 
bug.

Alternatively, to avoid falling in this historical trap again, switch the 
default around, rename this method to enableNameExpansion(), remove all calls 
to disallowNameExpansion(), and the few necessary calls to 
enableNameExpansion() in the old-native-format filters.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5