On Jun 19 21:24, Achim Gratz wrote: > Corinna Vinschen writes: > > The implementation of -E is a bit lacking, IMHO. > > Fair enough. > > > The description implies that the ephemeral file list gets "also" rebased. > > So I take it that there are two lists of files, the ones which get > > rebased and are written back into the DB, and the ephemeral ones which > > get rebased but are not written back. > > The unwritten contract is that an ephemeral rebase can only be done if > the DB is in a stable state. But you are right, it is better to enforce > that.
If you really want -E to be an exclusive option, then what I'm missing is the enforcement on the command line. In theory, if you specify the -E option, neither the -T option should be allowed, nor specifying any additional files on the command line. Right now, either the -E or the -T option will be silently ignored. Even more puzzeling, if you specify something like this: -E filelist1 -T filelist2 file1 file2... the -E option will set the global image_ephemeral_flag, but the list of files will *not* be taken from filelist1, but from filelist2, as well as from the command line. > > Another problem is this. The idea of the DB stuff is to make sure that > > the DLLs on the system are rebased in a compact way. Since your > > ephemeral DLLs are handled exactly like the persistent DLLs in > > merge_image_info, the ephemeral and persistent DLLs memory addresses > > will be blended together. So you generate holes in the memory layout > > of the persistent DLLs, which is kind of contrary to the idea behind > > this. > > This only happens if the DB is unstable (I think). Since I now do not > touch anything not in the DB, this should be no concern anymore. It is > intended that ephemeral DLL use holes in the mapping if they are > available, otherwise I could just rebase down from the lowest base > address. Hmm. [...time passes...] The longer I think of it, the more I'm wondering if you really need the -E option at all. The question is this: Why is it a problem to add ephemeral DLLs to the DB? And, is the distinction between ephemeral and persistent DLLs not kind of artificial? But let's keep the distinction for the sake of discussion. In theory you would want the ephemeral DLLs in the DB, too. After all, as long as they exist and are in use, they should blend together with the other, persistent DLLs without colliding with them. As soon as they disappear from the disk, the next rebase run will remove them from the DB as well, and another DLL can take the place (if it fits into the slot). The same happens with the persistent DLLs. If you remove the package containing cygncurses6.dll, a followup rebase(all) run will remove the DLL from the DB and it's memory slot is free for reuse. Given that, I don't see a qualitative difference between the DLLs from the distro and the DLLs you add manually, even if only for testing purposes. Ultimately they probably need rebasing, they should not collide with other DLLs, and they are removed from the DB when you remove them from the disk. Just like the so-called persistent DLLs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat