Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 467 of 808  Not logged in ELOG logo
ID Date Icon Author Author Email Category OSdown ELOG Version Subject
  66557   Wed Oct 7 16:17:34 2009 Question Steve WilliamsonStephenWilliamson@Barnsley.gov.ukQuestionLinux2.7.5Dynamic attribute values

Hi

I'm doing something wrong but can't work out what! 

I've created a new logbook with some date attributes that need to keep in step, e.g. one date ("receipt date") is set to the date the new record is created and another ("response required") to 7 days later.  The logbook doesn't use threaded messages, just a single page for each log entry with Submin/Preview/Back.  The dates are set with:

Preset Receipt Date = $date

Preset Response Required = $shell(gawk 'BEGIN{ print $Receipt Date + 86400 * 7}')

"receipt date" and "response required"  are set correctly when the log is written but if I change "receipt date" then "response required" is not altered - presumably because Preset only works on "New".  Tho I haven't found a way to make this dynamic with Subst.

When the log is updated later a third date may be entered ("proposal submitted") and this should calculate a fourth date ("proposal expires").  Again, I thought I could do this with some sort of "Subst" but can't work out how.  If I use Subst then the value of "proposal expires" isn't changed at all and if I use Subst On Edit then the value isn't changed until I go in to edit the log when the correct "proposal expires" date gets calculated and displayed, e.g.:

Subst On Edit Proposal Expires = $shell(gawk 'BEGIN{ if ($Proposal Sumbitted > 0) {print $Proposal Submitted + 86400 * 30}}')

Am I trying to do the impossible, and is there a document that will help me to understand when different updates (Preset, Subst, Subst On..., Change etc) happen and comparing their use?

A great piece of software - though I sometimes find it hard to get my head round all that it can be bent to do!

regards

Steve

 

  66558   Wed Oct 14 16:31:46 2009 Question soren poulsensoren.poulsen@cern.chQuestionLinux2.7.7Automatically 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 Reply soren poulsensoren.poulsen@cern.chQuestionLinux2.7.7Re: 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".

  66560   Fri Oct 16 12:17:15 2009 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux2.7.7Re: User authorization file corruption

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. 

  66561   Fri Oct 16 12:21:45 2009 Reply Stefan Rittstefan.ritt@psi.chRequestLinux2.7.7Re: Option list length

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.

 

 

  66564   Mon Oct 26 10:13:54 2009 Reply soren poulsensoren.poulsen@cern.chRequestLinux2.7.7Re: 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 Reply soren poulsensoren.poulsen@cern.chBug reportLinux2.7.7Re: 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 Reply soren poulsensoren.poulsen@cern.chQuestionLinux2.7.7Re: 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

ELOG V3.1.5-3fb85fa6