FileName::tempName() created a new temp file name by using qt to create a
temporary file with a unique name, and then deleting that file and returning
the name. This was unsafe, since other processes or even other threads of the
running LyX could create files with the same name between deletion and then
using the temp name.
This is fixed by using the TempFile class instead. As a side effect, a few
cases where the temp files were not deleted after usage were fixed as well.
The only place that is still unsafe is createTmpDir().
- The TempFile class guarantees to generate a file name, we are not limited to
100 tries of a predictable scheme anymore, which could break if LyX
frequently crashes.
- The temp file name generation has no race condition against another LyX
instance in the same directory anymore.
- Symlinks survive saving again (regression of 10364082c8).
FileName::tempName() is not thread safe, since the QTemporaryFile object is
immediately deleted after creating it. Therefore, another thread could create
the same temporary file in the time span before the user of FileName::tempName()
recreates it. This is not as theoretical as it may look: I observed that
repeated creation and deletion of QTemporaryFile objects always use the same
name.
This problem is solved by the new class TempFile which should be used like
QTemporaryFile itself.
If no mask is supplied or the mask is attached to the end of the filename, we end up with unexpected names like
<system-temp-dir>\lyx_tmpdir.qHp780.vcr780_<mask>
instead of a temporary file in the lyx temporary directory like
<system-temp-dir>\lyx_tmpdir.qHp780\<mask>.vcr780.
DVI viewer passes back the resolved path, such that the search fails,
as internally LyX uses the unresolved path.
This patch fixes this bug by using the new method FileName::realPath
which resolves a path by getting rid of any '.', '..', or symlink
path components.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@29476 a592a061-630c-0410-9148-cb99ea01b6c8
We need to solve these warnings from documentations:
* This will not compare two different symbolic links pointing to the same file.
* Long and short file names that refer to the same file on Windows are treated as if they referred to different files.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@25960 a592a061-630c-0410-9148-cb99ea01b6c8
The problem stems I guess from the use of from_local8bit().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@25809 a592a061-630c-0410-9148-cb99ea01b6c8
currently the whole path is (possibly with some unmotivated ... in
the middle) used which is usually far too long.
The algorithm implemented here will start with absolute paths. From
left to right path segments are added to the display string if they
help to make the display strings more unique. Otherwise nothing is
added, or if some middle path segments are omitted otherwise, three
dots ... are used.
The result is that we get just the base filename without extension if
they are unique in the tabbar.
The patch is open for discussion. If there is demand we can create
yet another preference option to get back the old behaviour.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@24555 a592a061-630c-0410-9148-cb99ea01b6c8
* src/insets/InsetExternal.cpp: fix compiling. (Does not work yet)
* src/insets/InsetGraphics.cpp: use latexFilename to produce output.
* src/insets/InsetGraphicsParams.cpp: use availableFile to show preview.
* src/EmbeddedFiles.h|cpp: More things are moved from EmbeddedFiles to EmbeddedFile
* src/frontends/qt4/GuiGraphics.cpp: remove embeddable-related operations.
* src/support/FileName.h: make isReadableFile virtual
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@22410 a592a061-630c-0410-9148-cb99ea01b6c8
* BufferView:
- insertPlaintextString(): now accept a FileName.
- contentsOfPlaintextFile(): ditto and use FileName::fileContents().
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@21915 a592a061-630c-0410-9148-cb99ea01b6c8
