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? -lThread Previous | Thread Next