Georg Baum <[EMAIL PROTECTED]> writes:
> > Nor it is necessary to also overwrite included material with a copy
> > from the lyx tmpdir, thus modifying the timestamp of a file.
> > http://bugzilla.lyx.org/show_bug.cgi?id=2434
>
> Last time I tried I could not reproduce this bug. This behaviour is not
> intended, and if anybody is able to reproduce that I'll be glad to help to
> fix that. The intended behaviour is to only overwrite files that would be
> generated by LyX. For .tex files this means if they are exported from a LyX
> file.
Actually, what would make sense here is to use a checksum to test whether LyX
should overwrite an existing file. Logic would go something like this:
Scenario 1:
LyX document contains graphics inset to foo/bar.eps
foo/bar.eps does not exist.
LyX generates LaTeX document with placeholder for missing graphic.
Scenario 2:
LyX document contains graphics inset to foo/bar.eps
foo/bar.eps exists.
LyX generates LaTeX document with \\includegraphics{foo/bar.eps}
Scenario 3:
LyX document contains graphics inset to foo/bar.png
foo/bar.eps does not exist.
LyX generates LaTeX document with \\includegraphics{foo/bar.eps}
LyX generates foo/bar.eps and generates checksum for the generated file. If
foo/bar.png subsequently changes, LyX will check to see whether it can
overwrite foo/bar.eps by comparing a newly generated checksum of the file to
the one held internally to see whether LyX "owns" this file.
If LyX "owns" the file, it overwrites it silently.
If LyX doesn't own the file, then in GUI mode it can prompt the user whether
he wants the file to be overwritten. In non-GUI mode LyX should presumably not
generate a new foo/bar.eps. (Unless a command-line flag "overwrite graphics"
has been set.)
Scenario 4:
LyX document contains graphics inset to foo/bar.png
foo/bar.eps exists already.
This case is similar to the one above when foo/bar.png is changed. LyX doesn't
hold a checksum for foo/bar.eps so recognizes that it doesn't own this file.
Does that cover all bases?
Angus
