On 02:32 PM 12/11/2001 -0500, Abd ul-Rahman Lomax said:
>Yes, it is correctly called a "buglet." Protel commands inherently rooted 
>in one database should never write to files in another database, even if 
>they are open. Further, if, for some reason, the filename alone is going 
>to be used in a process, instead of a full name including the database 
>name, then checking should be done for the presence of duplicate files. In 
>this case, the damage is small, removing those scribbled error markers is 
>practically one-button. That might not be true with, for example, an 
>update from library, where it could be disastrous.
>[EMAIL PROTECTED]
>Abdulrahman Lomax
>Easthampton, Massachusetts USA

I think it is a bug.  Pure and simple.

Those with long memories will recognize this as similar to the warning and 
loss of data that could occur when two like named but different pathed DDB 
files were being manipulated on a multiple machines on a network.  The 
corruption occurred when one file was saved and the other user was prompted 
to reload the saved changes - thus possibly loosing uncommitted changes 
they had made.

The similarity is that the software was working off name only and not the 
full path.  I think it is reasonable that we expect that when a 
characteristic error is found in one part of the program, an assessment is 
made on whether that bug could exist in other parts of the program.  That 
is certainly the sort of assessments we make in during our bug 
fixes.  Maybe I am being a little unfair here, though.  They may be quite 
unrelated (one is related to network traffic after all).

It has taken quite a while for this bug to become apparent (to this list at 
least) so it is possibly reasonable to assume that the name-only matching 
is not wide spread throughout the program.  Maybe someone in Protel R&D 
could assess this though...

Those bored of my rantings should drop off here...  Maybe the forum should 
have a poll on those users they wish would shut up most :-).

This is especially wired as the SDK makes use of a full path names that 
burrow inside the hierarchical structure of the DDB - just like a disk 
file.  So there is really no reason why a full path comparison should not 
be made.  It is even weirder when you consider the Sch project iteration 
examples that are provided by the SDK - I would think it was difficult to 
make the mistake as to which Sch should have the markers as once the 
project is iterated, the example at least, uses a stored handle to access 
them - not the name.  So I remain a little confused as to why the bug 
should occur at all.  But I am sure there is a good reason for the current 
implementation.

(Why am I discussing the SDK when the NDA has not been rescinded?  This 
aspect of the SDK was part of the original SDK release,  I "signed" the NDA 
for this part over a year ago so the 12 months timeout clause in the NDA 
has come and gone.  Now the SDK *updates* for SP6 are still probably 
covered. Bit of a silly situation.)

Bye for now,
Ian Wilson

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
*
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to