Possible bug: Incorrect deleting of articles upon saving
Possible bug: Incorrect deleting of articles upon saving
Alex, I may have found a bug for you. Easy to reproduce. Ok, in Properties-Article tab I have configured UE as:
Saving attachments:
Ask for delete: OFF
Mark read: ON
Delete bodies: ON
Delete headers: ON
Don't delete incomplete bodies: ON
Now, let's say I download immediately a bunch of images (Alt-I). I see some of them, and I decide to get the whole set. I select them all (including the ones that I had already downloaded and viewed) and press Control-D to download & save them all. Upon saving the attachments, UE does not delete some (neither bodies nor headers) of the images I had already downloaded and viewed.
I also just tried Alt-I about 50 articles with images. After UE downloaded them all, I selected them and hit Control-D. Out of those 50 articles, 46 got deleted (as they should) but 4 remained undeleted (both headers and bodies). All of them were successfully saved.
It should be easy to reproduce, Alex. I've been seeing this a lot.
Take care.
Saving attachments:
Ask for delete: OFF
Mark read: ON
Delete bodies: ON
Delete headers: ON
Don't delete incomplete bodies: ON
Now, let's say I download immediately a bunch of images (Alt-I). I see some of them, and I decide to get the whole set. I select them all (including the ones that I had already downloaded and viewed) and press Control-D to download & save them all. Upon saving the attachments, UE does not delete some (neither bodies nor headers) of the images I had already downloaded and viewed.
I also just tried Alt-I about 50 articles with images. After UE downloaded them all, I selected them and hit Control-D. Out of those 50 articles, 46 got deleted (as they should) but 4 remained undeleted (both headers and bodies). All of them were successfully saved.
It should be easy to reproduce, Alex. I've been seeing this a lot.
Take care.
yes i'll check that, it is also in the to do list for some time, just with this indexing put everything else aside.
i saw it once but it was on larger groups with partials so a bit difficult to track.
i noticed only single messages are affected and it seems the attachments are saved.
does it happen also in image groups? when there are no partials at all too?
it would be easier to reproduce then.
say series in 20 images and some images won't be saved? is there difference between 'download&save' and 'save'? if there is no difference with 'save' it happens in the same way always (e.g. you download bodies and invoke the same operation again, the same bodies aren't deleted)?
if so can you direct me to a group and messages (private message ok), it would be easy to fix then (just now i'm working on global strategy for crash elimination, so i'm a little not there ).
i saw it once but it was on larger groups with partials so a bit difficult to track.
i noticed only single messages are affected and it seems the attachments are saved.
does it happen also in image groups? when there are no partials at all too?
it would be easier to reproduce then.
say series in 20 images and some images won't be saved? is there difference between 'download&save' and 'save'? if there is no difference with 'save' it happens in the same way always (e.g. you download bodies and invoke the same operation again, the same bodies aren't deleted)?
if so can you direct me to a group and messages (private message ok), it would be easy to fix then (just now i'm working on global strategy for crash elimination, so i'm a little not there ).
Alex, I will do some more controlled reproduction testing on this, and hopefully I will answer your questions. I can answer one right now, actually. In my case, those images were not multipart, they were single-part articles. So, yes, it happens on those too.
I didn't actually try just "save" (Alt-A), only "Download&Save" (Control-D). But I will do some more testing with different variables to narrow this down.
I didn't actually try just "save" (Alt-A), only "Download&Save" (Control-D). But I will do some more testing with different variables to narrow this down.
if it happens with "save" as well it should be quite reproducible.
but i remember i saw it then happenning on save.
just i saved then large bunches of multiparts (not testing but just saving) and saw that a single (in the sense not partial) header with body containing attachment left. but headers were quite old, from several months ago and the whole database is currently 27.6GB, it will take a while to copy it
but i remember i saw it then happenning on save.
just i saved then large bunches of multiparts (not testing but just saving) and saw that a single (in the sense not partial) header with body containing attachment left. but headers were quite old, from several months ago and the whole database is currently 27.6GB, it will take a while to copy it
I came here just to report a similar problem and found the thread;
i usually download without saving a set of images, usually manga scanslations, later when they're downloaded i select them again and hit download+save and a panel asking where i want to save the attachment popup; here i have the second issue, i hit to create a new directory and a new folder named 'new folder' is created but not selected for rename it, so i have to search for 'new folder' and rename it, while on newspro when creating a new dir you can change the name just after hitting the 'create folder' button.
Next i get the same problem, same header+body are not selected, maybe not saved since a saw quickpar working sametimes to recover same files.
The problem is easy to get if you try downloading group of pics form alt.binaries.pictures.anime that usually carry groups of 200 or 300 pics but i noticed that the number of pics does not affect the number of not deleted headers+bodies.
Then i select the headers+bodies and hit download&save again, they're saved now but the last group of saved pics is automatically undeleted, marked read and marked for download&save.
es. i have a bunch of pics, 100 of them , i mark them for download , i came home later , select all them and do a download+save;
Ue start immediately to save pics and deleting header&body but 3 or 4 of them are not deleted (on ABPEA like i mentioned it happen half the times).
I select the 3 or 4 not deleted pics and hit download+save again, then 1 time every 3 all the previous 96 pics appears from nowhere marked read and marked for download+save so UE start download again; i never checked what happened to the last 3-4 pics i was saving so i don't know but all pics are saved.
Note that because my preferences every time i have asked for the location where to save.
i usually download without saving a set of images, usually manga scanslations, later when they're downloaded i select them again and hit download+save and a panel asking where i want to save the attachment popup; here i have the second issue, i hit to create a new directory and a new folder named 'new folder' is created but not selected for rename it, so i have to search for 'new folder' and rename it, while on newspro when creating a new dir you can change the name just after hitting the 'create folder' button.
Next i get the same problem, same header+body are not selected, maybe not saved since a saw quickpar working sametimes to recover same files.
The problem is easy to get if you try downloading group of pics form alt.binaries.pictures.anime that usually carry groups of 200 or 300 pics but i noticed that the number of pics does not affect the number of not deleted headers+bodies.
Then i select the headers+bodies and hit download&save again, they're saved now but the last group of saved pics is automatically undeleted, marked read and marked for download&save.
es. i have a bunch of pics, 100 of them , i mark them for download , i came home later , select all them and do a download+save;
Ue start immediately to save pics and deleting header&body but 3 or 4 of them are not deleted (on ABPEA like i mentioned it happen half the times).
I select the 3 or 4 not deleted pics and hit download+save again, then 1 time every 3 all the previous 96 pics appears from nowhere marked read and marked for download+save so UE start download again; i never checked what happened to the last 3-4 pics i was saving so i don't know but all pics are saved.
Note that because my preferences every time i have asked for the location where to save.
in newspro i used my own directory dialog, i can move it to UE as a (temporary?) option, since in the next Windows version (Vista) it seems the "new folder" problem has been resolved (if i found it right Vista will be released at 23 July 2006).
with saving i'll check with picture groups, if it happens on save i'll fix it pretty fast then.
with saving i'll check with picture groups, if it happens on save i'll fix it pretty fast then.
ok, i've fixed it here, was a relatively innocuous synchronization bug, it saved the attachment but concurrently could reset a flag in a previously saved attachemnt which caused aborting the check for marking read/deleting for the attachment which has just been successfully saved. it is why i saw it always behaving differently.
thus the bug will be gone in v1.15 and my old to do list
thus the bug will be gone in v1.15 and my old to do list
Yup. It's fixed. I've been trying it for a little while now and it seems to be gone. You squashed it
You know, I am not a programmer, but for some reason I thought it might be a thread synchronization issue perhaps? Is that what you mean by synchronization?
On another note, Alex is it possible to add descript.ion logging support to UE? This has been on my "wish list" for NewsPro for years. Should be simple enough to do, too. Just a simple ASCII file.
UE is turning out great. Thanks for all your hard work.
-ilias.
You know, I am not a programmer, but for some reason I thought it might be a thread synchronization issue perhaps? Is that what you mean by synchronization?
On another note, Alex is it possible to add descript.ion logging support to UE? This has been on my "wish list" for NewsPro for years. Should be simple enough to do, too. Just a simple ASCII file.
UE is turning out great. Thanks for all your hard work.
-ilias.