IsAstack ( )

[David Bovill]

I have not found any problems with name space collision using the technique
Chipp described. Locking messages and loading a stack with the same name
into memory seems fine - you just remove it from memory using the file name
(long stack name). I tested it quite a bit and routinely run through 40 or
50 stacks searching for stuff (they often have man duplicates and so
duplicate names and sometimes they are corrupted).

I do it regularly but not that often to claim it is totally bug free - but
would very much like to see if anyone can find an example where it does not
work?

On 13/07/07, Trevor DeVore <lists at mangomultimedia.com> wrote:
>
> On Jul 13, 2007, at 1:29 AM, Chipp Walters wrote:
>
> > So, what to do if there already is a stack with the same name open?
> > Just curious, would this work?
> >
> > lock messages
> > if there is a stack tStackPath then
> >  put true into tExists
> >  delete stack tStackPath
> > else
> >  put false into tExists
> > end if
> > unlock messages
> >
> > I would think this would work even with namespace collisions, as the
> > delete stack explicitly names the stacks filepath.
>
> Chipp,
>
> I haven't tried the above code but using "if there is a stack" does
> load a stack into memory so I would think the collision would happen
> with that call. What Jerry and I did for Galaxy was write a function
> to extract the stack name from disk before trying to open it. That
> was the only reliable method we found to circumvent the problem.
> But not even that works if there is a substack that will cause a name
> collision.
>
> --
> Trevor DeVore
> Blue Mango Learning Systems
> www.bluemangolearning.com    -    www.screensteps.com
> trevor at bluemangolearning.com
>
>
> _______________________________________________
> metacard mailing list
> metacard at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/metacard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.runrev.com/pipermail/metacard/attachments/20070713/989bdceb/attachment.html