View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016853||Scribus||Graphics / Image Frames||public||2022-10-31 17:26||2023-02-26 23:24|
|Summary||0016853: Imported graphics disappear an delete the sourcefiles on the HDD|
|Description||In the meantime I am close to despair: In a book manuscript (approx. 120 pages) I use pictures (photos of size 66x92 mm). All pictures are marked accordingly so that they are saved in the document. Again and again it happens that some of the pictures are no longer displayed for no apparent reason. Instead, a link appears (e.g. Scribus_temp_LWCENv.jpg), but it leads nowhere. Each time I have to re-insert the image, but it has also been deleted from the HDD in the directory. The setting "low resolution" also brought no improvement.|
|Steps To Reproduce||?|
|Tags||No tags attached.|
>> Again and again it happens that some of the pictures are no longer displayed for no apparent reason.
This is a common symptom of computer running out of memory.
When layouting a document with lots of images, it is generally a bad idea to embed the images in the document as embedding the images in the document will increase the memory usage and also make the document more fragile to corruption. Image embedding should only be used with small images and only when there are only a very few to embed in the document. If you embed all the pictures of your document, you should consider you are doing it wrong.
||Do have steps to reproduce the deletion of the originally imported image? We already fixed a similar issue in 1.5.7, i cannot reproduce this kind of deletion in 1.5.8 currently.|
Scribus 1.5.8 seems to cleanup all files in the %TEMP% folder on application start -- including those of an already running instance.
If the Scribus document loaded in the first instance is saved, all embedded pictures get lost without any error message.
18.104.22.168 is able to correctly handle embedded images of multiple documents.
>> Scribus 1.5.8 seems to cleanup all files in the %TEMP% folder on application start
No, it does not. However when closing a document containing embedded images, all temporary files corresponding to embedded images data in the document will be deleted. This is expected behavior.
>> If the Scribus document loaded in the first instance is saved, all embedded pictures get lost without any error message.
Just did a test with several documents containing embedded images opened in different instances. I could not reproduce an issue.
||If you;re storing anything in %TEMP% intentionally, you could lose them. Other system processes can also clean up that location.|
I cannot reproduce it with the files currently at hand on a different machine. The installation on the other PC must not be changed until the document will be finished.
But it happened several times before the downgrade to 22.214.171.124. All Scribus-generated temp files were deleted when opening a second instance.
> If you;re storing anything in %TEMP% intentionally, you could lose them. Other system processes can also clean up that location.
Of course, I do not do this. I have just watched what was going on in %TEMP%.
Scribus creates copies of the embedded images in %TEMP% on document load.
> However when closing a document containing embedded images, all temporary files corresponding to embedded images data in the document will be deleted. This is expected behavior.
PS: I hate Mantis. It has not been the first time that it denies and discards the entered text due to a token timeout.
|2022-10-31 17:26||gruppe-913||New Issue|
|2022-10-31 20:43||jghali||Note Added: 0049799|
|2022-10-31 22:33||jghali||Note Edited: 0049799|
|2022-11-06 01:47||jghali||Note Added: 0049809|
|2023-02-25 20:46||mstv||Note Added: 0050002|
|2023-02-25 22:04||jghali||Note Added: 0050003|
|2023-02-25 22:25||jghali||Note Added: 0050004|
|2023-02-26 14:17||cbradney||Note Added: 0050005|
|2023-02-26 23:24||mstv||Note Added: 0050006|