> Well, we need some general solution, because there are similar problems
> elsewhere. If you have a file that contains a path to an included file,
> for example, it can be changed simply by opening and saving the file. In
> particular, it will always be converted from an absolute to a relative
> path, and relative paths can be changed when you save. (With graphics,
> it seems you can't even store an absolute path, which seems wrong, too,
> but this is an older issue.) The problem, in general, seems to me to be
> that the updateEmbeddedFile method is modifying the path to the included
> file. I can see why it might need to modify the embed parameter, but why
> should it be modifying anything else? Is there some reason we need the
> first line:
> void InsetInclude::updateEmbeddedFile(EmbeddedFile const & file)
> {
> setParam("filename",
> from_utf8(file.outputFilename(buffer().filePath())));
> setParam("embed", file.embedded() ? from_utf8(file.inzipName()) :
> docstring());
> }
> That's the offender. I don't think removing it affects the copyTo()
> issue. That's handled in setBuffer().
I know, this is again because we can not recover the relative path
reliably. My orignal idea is that we have the absolute path, and we
get the relative path when needed, and different relative path will be
obtained from different buffer....
> In the case of InsetBibtex, I think maybe an approach more like the one
> in InsetInclude might work, where there aren't any "local" EmbeddedFile
> objects but only the ones in the Buffer-level EmbeddedFileList.
> InsetBibtex could have a vector of EmbeddedFile* instead, where these
> are returned by registerFile(). So far as I can now see, the
> EmbeddedFile objects aren't actually doing anything in InsetBibtex but
> are, again, acting more as intermediaries. Removing them from
> InsetBibtex would mean a few changes elsewhere, too, but not many, and
> it would restore the "purity" of the inset.
But you do need something to store the bibfiles, and I, by instinct,
dislike parsing params['blah'] again and again...
I have proposed in another email to save relative path in
EmbeddedFile, which will no longer derive from DocFileName, but will
return external or embedded FileName is needed. I think this would
solve the problems.
Bo
