William F. Maddock wrote: > On Mon, 2008-04-28 at 11:01 -0400, Gregory Pittman wrote: > >> Well, yes this is a Linux feature. Prior to Linux, the standard desktop >> computer behavior was to not allow one to start up a program already >> running. If Windows or Macs or whatever behave this way now, it's an >> adoption of this Linux behavior, not something they invented. >> > > Actually, Amiga was doing this before Linux ever showed up on the scene, > and Amiga got it from Unix. Mac probably got it from Unix as well. Can't > say about Windows
Furthermore, Windows applications are free to appear to open a file many times too. The only restriction in Windows is against opening a file while there's an existing file handle (and even that's actually a rather weak limitation - it depends on which API calls you use, what mode the existing file handle was opened with, etc). As many programs read a file into RAM they can and often do just close the file handle. Scribus could just keep a file handle open for the file after reading it in, and release it when the document is closed. That'll prevent another instance from opening it again, and it can use other internal checks to detect whether the same instance is reopening the file. However, that'll only work for Windows and keeps a file handle open needlessly; I'd instead want to see if Windows has any sort of advisory locking. On Unix/Linux the best choice is advisory locking with fadvise() and friends. On Mac OS X it depends on the APIs you use. With the Carbon file APIs you get Windows-like automatic mandatory locking. With the POSIX/BSD calls you get UNIX-like behaviour. Again, though, advisory locking is probably better. That's a lot of platform specific messing around, though, for a pretty trivial feature. Personally I wouldn't bother. -- Craig Ringer
