Warren Young wrote:
Postponing postinstall scripts that depend on scheduled
file installation? Fuggetaboutit.
Can we postpone the script execution, too?
Another possibility occurs: instead of hiding all the MoveFileEx() stuff
inside setup.exe or rpm.exe, can cygwin1.dll be asked to do it? This
would let it build a map of temporary file names and the paths they will
be moved to during the next reboot. If a process later tries to open(2)
one of these files, the replacement copy gets loaded from its temporary
location, rather than the file that's about to be replaced. As long as
no one checks inodes, this mechanism would be transparent. (It could
fake the inode, too, if it had to.)
This behavior should probably be optional, enabled by a call to a new
Cygwin v1.7 DLL interface. Call it cygwin_enable_delayed_move().
rpm.exe can call this early on, before attempting the install. Another
interface, cygwin_delayed_moves() would return nonzero to setup.exe to
tell it to tell the user that a reboot will be needed to finish the install.
When this mode is enabled, unlink(2) and rename(2) call MoveFileEx() in
the "return EBUSY" case, returning 0 instead. They can pretend that the
move succeeded, because any further accesses to the file to be replaced
will access the temporary copy which will become the new one on the next
reboot, rather than the doomed copy.
The hash lookup will be a performance hit, but you pay it only after
someone's enabled this behavior *and* there's an in-use file that had to
be scheduled for a delayed move. Normally there's just a quick check
for an empty hash map, which lets it know that it can take the normal
code path.
