| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
66553
|
Fri Sep 18 07:32:38 2009 |
 | soren poulsen | soren.poulsen@cern.ch | Request | Linux | 2.7.7 | Option list length | Hi,
I use the following attribute definition:
Options <attribute> = <list>
However, I am being limited by the list length limit of 100. I have 103 items, but I only see 100.
Could the limit be extended (to 200 for instance) ?
Thanks a lot for your help
Soren
|
|
66554
|
Fri Sep 18 07:39:02 2009 |
 | soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.7 | User authorization file corruption | Hi,
Here is what happens (I think) if E-log encounters a full file system where it keeps the user authorization file:
1. When a user connects, E-log will make a backup of the file. The backup will be corrupt since the file system is full.
2. E-log will modify the contents of the original file, and write it back. The file will be corrupt since the file system is full.
3. Now, both the backup and the normal file are corrupt and you cannot log on, until someone cleans up the file system and restores a valid copy of the file.
Would it be possible to fix this ? Like abort if step 1 is not successful. And restore the backup file if step 2 is not successful.
Thanks a lot for you help
Soren |
|
66558
|
Wed Oct 14 16:31:46 2009 |
| soren poulsen | soren.poulsen@cern.ch | Question | Linux | 2.7.7 | Automatically generated incrementing tags (#) | Hi,
I am using the # character to generate automatically incrementing numbers for new messages.
My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".
So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.
Maybe someone has a solution to this ?
Soren Poulsen
|
|
66559
|
Wed Oct 14 16:46:57 2009 |
 | soren poulsen | soren.poulsen@cern.ch | Question | Linux | 2.7.7 | Re: Automatically generated incrementing tags (#) |
| soren poulsen wrote: |
|
Hi,
I am using the # character to generate automatically incrementing numbers for new messages.
My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".
So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.
Maybe someone has a solution to this ?
Soren Poulsen
|
The solution is to use "Subst" instead of "Preset". |
|
66564
|
Mon Oct 26 10:13:54 2009 |
| soren poulsen | soren.poulsen@cern.ch | Request | Linux | 2.7.7 | Re: Option list length |
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
Hi,
I use the following attribute definition:
Options <attribute> = <list>
However, I am being limited by the list length limit of 100. I have 103 items, but I only see 100.
Could the limit be extended (to 200 for instance) ?
Thanks a lot for your help
Soren
|
You can change that yourself. Just find following line in elogd.c:
#define MAX_N_LIST 100
and change it to 200, then recompile. But you are there on your own, at some point you will get a stack overflow and elogd will crash, but I don't know exactly where this limit is.
Anyhow I would propose that if you have so many options in an attribute, that you better go and group these options somehow. Like using two attributes, where the first defines the group, and the second gets different list for each option of the first attribute using conditional attributes. Have a look here.
|
Thanks. This is a good explanation. It might indeed be better to re-group the options to have a shorter list.
Soren |
|
66565
|
Mon Oct 26 10:15:20 2009 |
| soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.7 | Re: User authorization file corruption |
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
Hi,
Here is what happens (I think) if E-log encounters a full file system where it keeps the user authorization file:
1. When a user connects, E-log will make a backup of the file. The backup will be corrupt since the file system is full.
2. E-log will modify the contents of the original file, and write it back. The file will be corrupt since the file system is full.
3. Now, both the backup and the normal file are corrupt and you cannot log on, until someone cleans up the file system and restores a valid copy of the file.
Would it be possible to fix this ? Like abort if step 1 is not successful. And restore the backup file if step 2 is not successful.
Thanks a lot for you help
Soren
|
Ok, I finally found some time (I'm pretty busy these days) to add a check for a potential full file system in SVN revision 2258. So before the password file would get corrupted, elog shows an error message about the full file system and just stops to work until space is freed up.
|
Great. We fully appreciate that your are busy (with other things than E-log).
Thanks for the resolution.
Soren |
|
66566
|
Mon Oct 26 15:43:55 2009 |
| soren poulsen | soren.poulsen@cern.ch | Question | Linux | 2.7.7 | Re: Automatically generated incrementing tags (#) |
| soren poulsen wrote: |
|
| soren poulsen wrote: |
|
Hi,
I am using the # character to generate automatically incrementing numbers for new messages.
My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".
So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.
Maybe someone has a solution to this ?
Soren Poulsen
|
The solution is to use "Subst" instead of "Preset".
|
This is not really resolved, since "Subst" creates a new number on both "New" and "Reply". I would like "Subst" to create a new number only on "New" and preserve this number through replies throughout the thread. I would like to be able to say "Subst thread = #" to make a new number for the thread and combine it with "Subst on reply thread = $thread" to preserve the number on replies, but this does not work. Maybe someone has already done this ?
Soren |
|
66582
|
Sun Nov 8 23:25:25 2009 |
| soren poulsen | soren.poulsen@cern.ch | Question | Windows | 2.7.6-2236 | Re: Elog & SSL Export to CSV , Problem |
| Chuck Brost wrote: |
|
| Stefan Ritt wrote: |
|
| Chuck Brost wrote: |
|
Ah, now this is humorous, when the client first came to me, that was almost exactly the work around I gave him, open it, CTRL-A to highlight it all, CTRL-C to copy it, Move to the excel spreadsheet, CTRL-V to paste it into Excel. Select Data, Text to Columns, and you have an Excel Spreadsheet. They wanted me to post the change in function anyway, though I told Vamsi, "just watch, someone will post the same workaround that I already gave to the clients". So you see why I find it amusing. I would say Great Minds Think Alike, but that would be giving myself a bit too much credit (grin). First, thank you for proving me right on my prediction and if you should happen to make a change that would get around this SSL change in behavior, it would make a group of manufacturing types that are not quite as comfortable with computers as we are, very happy. Please let us know.
|
I can easily remove the "no-cache" from the header, but as I wrote you, people can then shoot themselves into the foot by getting an old document, and I guess they become even less happy then. So you tell me which way you prefer.
|
Trust me, I don't want them getting old data either.. that would be a nightmare..
of course, the little voice at the back of my head (note, not IN the back of my head) has offered up this tidbit for you to consider.
Stefan, would it be possible to make the following change so that the document is not cached and at the same time it is possible to save it.
The change would entail replacing the "Pragma: no-cache" directive with an "Expires: " <HTTP-date> where <HTTP-date> is the same as Date header value. Please see section 14.21 of http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Hopefully there are no other side effects to this change.
|
You can also try to use a different browser.
Soren |
|