Returning to this 8+ months later ... On Mon, Sep 6, 2021 at 9:29 PM Bart Schaefer wrote: > > Open a database as a global and assign something to it: > [...] > Now start messing with the declaration in a function: > [...] > As soon as the tied parameter is declared local, the file has been > written, erasing all the existing values. This seems undesirable? > [...] > Untying the local destroys the global, too, and leaves the file as the > local wrote it. > [...] > I think the correct thing might be to prohibit changing the scope, > similar to what happens when an attempt is made to remove the readonly > attribute? > [...] > Re-ztie-ing the database file while it is still tied, is already > handled as an error. Looking into how this might be accomplished, I noticed this: #ifndef PM_UPTODATE #define PM_UPTODATE (1<<19) /* Parameter has up-to-date data (e.g. loaded from DB) */ #endif I don't think that's a safe choice of bitflag any more? That was introduced 2017-02-16, but the PM_ bit values were rearranged 2018-10-12 and bit 19 is now PM_LOCAL. That doesn't have any effect on the aforementioned behavior of "local"/"zuntie", but perhaps something like this is better? -#ifndef PM_UPTODATE -#define PM_UPTODATE (1<<19) /* Parameter has up-to-date data (e.g. loaded from DB) */ +#ifndef PM_UPTODATE /* Parameter has up-to-date data (e.g. loaded from DB) */ +#define PM_UPTODATE PM_DONTIMPORT_SUID /* Safe PM_ bit to re-use */ #endif Back on the original issue, the simplest way to fix this appears to be to declare the ztie'd parameters to be PM_SINGLE. % zmodload zsh/db/gdbm ztie -d db/gdbm -f sample.gdbm sampledb % () { local sampledb typeset +m sampledb } (anon):local:2: sampledb: can only have a single instance % Patch attached. Comments welcome.