2 bugs: the Profile Copier addon and CRopen()

All notes and input on 2.0 Development are herein. <ul><li>Feature requests</li>
<li>Bug Reports</li>
<li>Beta Testing Feedback</li>
<li>Open Dev Discussion</li></ul>

Moderator: Coranto Moderator Team

2 bugs: the Profile Copier addon and CRopen()

Postby Parahead » Thu Aug 18, 2005 6:41 pm

Just wanted to report about a bug I just found in the Profile Copier addon, version 1.01. Or, actually it is two bugs, one in that addon and the other in Coranto.

The bug in the PC addon is basically caused by the fact that it doesn't handle the 'Display Name' option available in the profiles, which has been in Coranto since 1.03, so I am a little surprised that I am the only one reporting about this problem. Anyway, the problem appears when a profile which has the same Display Name as the internal name is copied. The addon asks at that point for a new name for the profile, but the display name is not changed, and since it then has the same name as the old profile it is 'hidden' when viewing the Profile overview page in Coranto, but it really is there 'behind the scene'.

TEMPORARY SOLUTION: When the above happens, specify another Display Name for the profile and the fresh copy will appear (with the old Display Name but with the new internal name).

LONGER TERM SOLUTION: http://coranto.org/forum/viewtopic.php?t=8793

The second bug may arrise for you as a result of the first one, but is a general problem. Since the second profile is a copy of the first one, it has the same outputfile specified. This is is a problem if you start doing a build and both the profiles tries and open the same file. If file lock is enabled (which it probably is) the second profile will start waiting for the file to be closed, which it never will since Coranto itself has opened it, and instead be caught in a deadlock. I experienced this in 1.24 but the building routine is changed in the development version 1.31.x so this does not happen there. Never the less, the CRopen sub in Coranto should handle the scenario of trying to open an opened file better anyway.

TEMPORARY SOLUTION: Don't use the same output filepath in different profiles! ;-)

LONGER TERM SOLUTION: Would be to use LOCK_NB as well as the LOCK_EX flag. I don't think that there is a need to use LOCK_NB when LOCK_SH is used though? There is a line in the sub CRopen (in file crcore.pl) that currently looks like this:
Code: Select all
my $flockflag = LOCK_EX;
which could be changed to this instead:
Code: Select all
my $flockflag = LOCK_EX | LOCK_NB;
This will result in a Coranto errormessage instead of a deadlock when trying to open a file for writing that is already locked. Feedback on this from any coders in the community? Any other/better suggestions for how to solve this?

My intention is to fix both of these issues at a later stage but for now I just wanted to report about them as soon as possible, not to cause other users headace...
Yes, I am still around...
www.parahead.com/coranto/
User avatar
Parahead
 
Posts: 4837
Joined: Fri Jan 12, 2007 8:54 pm
Location: Stockholm - Sweden

Return to Coranto 2.0 Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron