Front page | perl.makemaker |
Postings from January 2006
demerphq wrote:
> We dont need this behaviour as we arent going to be dealing with any
> DLL's that will be started prior to perl starting. Move at boot
> behaviour is only required for dlls that are loaded at boot. Since the
> files we care about are only locked because of Perl we only need close
> perl.
---
The Windows API "MoveFileEx" is used to move _any_ DLL that is
locked in memory. It isn't something primarily used by device drivers,
but by any "setup" or install program that replaces "DLL"s loaded in
memory.
You cannot rely on the DLL being unlocked when perl exits,
as a system may have another instance of perl that is running
and using the same Dll. It's quite possible to have a perl program
run at system startup -- that would make the DLL "inuse" while the
system is up.
> This needs more investigation. It has to be tested using native win32
> builds and not cygwin. At the very least Cygwin and native perl use
> different default permission masks when opening files. Also be wary of
> cygwin pretending its deleted a file when it has in fact turned on the
> delete on close flag of the opened file, theres nothing to stop
> another process from turning it back off afterwards.
---
"Delete on close"? I don't believe I'm familiar with such a
flag in Windows. Are you referring to the registry
values "PendingFileRenameOperations" and "PendingFileRenameOperations2"
that are populated with "move" operations that are to be done upon system
reboot? These are located under the regkey:
"HKLM\System\CurrentControlSet\Control\Session Manager".
This isn't a "flag", per se, that some other process could
turn off. The renames are textual strings added to the
value(s) above. There isn't a possibility of another process "accidently"
turning off a flag. Another process would have to open the registry keys,
find the pertinent rename operations in the "list of pending file move
operations", delete them, then rewrite the list back into the registry key.
I don't believe there are any Windows API's to do this. Some systemish
utilities allow listing or deleting the values from the keys, but they
write directly to the registry. Programs can't easily delete pending
"moves" unless they write directly to the registry routines to alter the
specific keys.
From the article "How to Move Files that are Currently in Use"
(http://support.microsoft.com/Default.aspx?id=140570):
"Sometimes Win32 applications need to delete, rename, or move files
that are currently being used by the system. One common example is
that setup programs need to remove themselves from the user's hard
disk when they are finished setting up a software package..."
The "MoveFileEx" API is supported on both win-nt and win-95 based
systems. The exact implementation is OS dependent. The MS-suggested
method to replace "inuse" files is to use this API. The extra bit
about "renaming the old-inuse" DLL, scheduling it for later deletion,
and copying the new file into place is only something I've tested on
NT-based systems. It's not something guaranteed [sic?] by MS, however.
It has the advantage of not requiring a reboot to use the new
DLL, but the deletion still needs to be scheduled to happen at reboot
to ensure all programs using the old library are closed.
> I think it sounds interesting, but its occured to me that maybe a
> better approach is to conceive of a way to prevent the files from
> being locked in the first place.
---
This isn't possible even on a unix-based OS. If a shared
library (.so) is loaded by some process and used as a demand-paged
library, the image on disk is used as backing store. On *nix based
systems, there is the advantage that the OS can keep open a file
inode to prevent it's deletion. Deleting the filesystem
reference (the file's name on disk) doesn't affect the actual
inode-based file. The file-space associated with the inode isn't
reclaimed by the OS until all processes have closed (no longer need)
the inode.
You can generate abnormal behavior on many *nix's if you
update an executable, "in-place": by copying the new file over the
old file's inode (ala "cat new.so >old.so"). Deleting the old
file first, guarantee's you won't overwrite an "inuse" inode.
In addition to the "movefile" utility, there is also
a "pendmoves" util that will list files to be deleted (by listing the
value(s) in the the earlier mentioned registry key(s)). You can read
about both utils (and download them) from:
http://www.sysinternals.com/Utilities/pendmoves.html
Perhaps I have not understood what you are trying to accomplish.
I thought you were talking about an error under CPAN where Cwd.pm doesn't
install correctly on Windows due to the Cwd.dll file being "inuse" when
the install script tries to copy it into place?
-l
Thread Previous
|
Thread Next