Soren, you're not alone!  I've had similar problems, as did Sara Vanini (elog:67077).

In my case, it is because the "move" or "copy" function does not move all the messages in very long threads.   To be more precise, elog will crash in the attempt to move a long thread - say over 40 replies, I don't know for sure.  Sometimes it has already moved the entire thread before it crashes, sometimes not.  I'd not flagged it up as an issue because I could not be sure it was not a memory issue with the old (>12 years) linux box I was using earlier this year, but it still happens on this new (to me, only 3 years old) linux box.

Whether it is the number of entries, the total memory size of the thread or some combination, I don't know.

I've found that in the "move" case, it has not deleted all the messages from the donor thread, so that there is a semi-thread still hidden there.  Should one by chance select that semi-thread, (because it is found during a search) elog goes into infinate loop, which requires a reboot of this linux box to fix.   Certainly the pinning down the issue to the missing entry referenced by an <i>In reply to:</i> explains this part of the issue.  Of course, deletion of one entry within a thread, or other adjustments will do the same thing, just as you (Soren) point out above.

If it happens to me, I will go in to the yymmdda.log files and fix the problem, be it deleting the entries of the semi-thread, moving across missing entries from the donor to the acceptor logbooks, adjusting the <i>Reply:</i> and <i>In reply to:</i> lines, but that is quite a time consuming and error prone exercise.

Is it possible to have an attachment to an entry in a different directory to the working directory of the logbook being used?

By which I mean, if you have in logbook hidden the attachment files

../logbooks/hidden/110705_235520_whatthis-0.png
../logbooks/hidden/110705_235520_whatthis.pdf

that an entry in another logbook, public, can use the entries in hidden to show them (and do everything that you can do with an attachment)
without making another copy in public?

I see that if, working in public, you attach the .pdf file in hidden, the files get copied across as

../logbooks/public/110705_235520_whatthis-0.png
../logbooks/public/110705_235520_whatthis.pdf

that is, with the original (hidden) timestamp, and no second time stamp superimposed.  From which you can gather I've been playing around, manually editing a yymmdda.log file to try and get the result I want, even if for the moment it cannot be done via elog; but without success, although there were some bizarre interpretations by the elog program of the edited yymmdda.log file, depending upon what I tried.

For one entry, it is of course no big deal, copying the files into the public directory, but if you are dealing with multiple huge entries, it does seem wasteful of HD space

But my reason for this is that hidden has restricted access, whereas public has general access.  The attachments themselves are not restricted, but comments, history etc around them in the restricted access logbook should not become available to the general viewer.

OK, so no-one has ideas as per my question in elog:67088.

Looking at the issue from another angle.

If you attach a pdf file (for example), two files are added to the logbook:

../logbooks/hidden/110705_235520_whatthis-0.png
../logbooks/hidden/110705_235520_whatthis.pdf

Is there any way that you can select an attachent, but only the thumbnail (.png in this case) is stored (and
subsequently viewed)?  Options for ability to select an attachment, or how the thumbnail is manipulated/viewed
exist, but nothing about the storage or otherwise of the original document that I can find.

I've tried manually deleting the .pdf file (after going through the automatic routine to make an attachment),
and elog doesn't seem upset at the lack of the .pdf file at all.  The only time anything happens is if one
clicks on the image - and then you get a 'file not found' message from the browser - I could live with that.

In my case the original .pdf file is elsewhere, I've no need to have duplicates scatted in various logbooks, and
while ideally that would also be true of the thumbnail, it is fair enough for this to be stored in each logbook
where it is required.  This removes the issue of how to have an attachment in a different logbook (other than by
links, which would get rather tiresome to have to keep making).

Anyone any ideas?

If you just want to show a thumbnail of an attachment in a public logbook, then just add a link to it. like

<img src="https://abk.web.psi.ch/tmp/t.png" alt="" />

or in your example you show the thumbnail in the hidden logbook by adding in the text body:

<img src="<your-host-url>/public/110705_235520_whatthis-0.png" alt="" />

Of course the attachment has to be in the public logbook and the link in the hidden one.

Sure, but that works only from a hidden logbook into a public one, not the other way, but I think this is what David wants. Since the hidden attachment is not accessible from the public logbook, there is no way around that other than physically copy the message, then strip maybe the text. He is concerned about having the same attachment twice on disk, which I cannot fully understand. Even large attachments are maybe 10 or 20 MB, otherwise they take forever to go through your browser. With a modern 1 TB disk these are 50.000 attachments... 

Hi Andreas,

>Of course the attachment has to be in the public logbook and the link in the hidden one.

The issue I have is that the attachment is in the hidden logbook, the link would have to be in the 
public one...

I'll also look again at putting in the links in the text (normally I use plain encoding, rather than html).

I wondered if there had been some flag for the config file whereby the original file for attachment was
processed by ImageMagick, but not stored, only the .png file(s) stored - or rather, some other way that achieved
the same end. as there is no such flag at present.

For now, anyway, I can attach the documents/pics I want, then go in and delete the 'originals' as saved in the
logbook, leaving just the .png files.  But maybe something for the wishlist?

Hi Stefan,

>Sure, but that works only from a hidden logbook into a public one, not the other way, but I think this is what
>David wants. Since the hidden attachment is not accessible from the public logbook, there is no way around that
>other than physically copy the message, then strip maybe the text. 

(as per my reply to Andreas)

>He is concerned about having the same attachment twice on disk, which I cannot fully understand. Even large
>attachments are maybe 10 or 20 MB, otherwise they take forever to go through your browser. With a modern 1 TB
>disk these are 50.000 attachments

I've not mentioned it, but the entire logbook directory and subdirectories have to squeeze into a memory stick,
along with other data not at issue here.   Soon be too much for an 8GB stick, so that a factor of 100 down on
the available memory space.

But I can work with the solution I gave in the reply to Andreas.

> I wondered if there had been some flag for the config file whereby the original file for attachment was
> processed by ImageMagick, but not stored, only the .png file(s) stored - or rather, some other way that achieved
> the same end. as there is no such flag at present.
> 
> For now, anyway, I can attach the documents/pics I want, then go in and delete the 'originals' as saved in the
> logbook, leaving just the .png files. But maybe something for the wishlist?

At least I now understood your problem :-)

You can have a script in your hidden logbook, that processes your attachments with "execute new", create thumbnails
of them (using ImageMagicks "convert") and submit those thumbnails as one additional entry to your public logbook.

But then you would get thumbnails of all attachments of the hidden logbook in the public one, maybe you don't want
that either? If you want them all, this method is more automated. If you just want some, do it as you suggested it.

In my opinion this is a rather exotic feature request :-)
I wonder if there is a second person in the world who could use it?