On 8/5/05, Randy W. Sims <[EMAIL PROTECTED]> wrote:
> demerphq wrote:
> > On 8/3/05, Randy W. Sims <[EMAIL PROTECTED]> wrote:
> >
> >>Piotr Fusik (via RT) wrote:
> >>
> >>># New Ticket Created by "Piotr Fusik"
> >>># Please include the string: [perl #36766]
> >>># in the subject line of all future correspondence about this issue.
> >>># <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36766 >
> >>>
> >>>
> >>>This is a bug report for perl from [EMAIL PROTECTED],
> >>>generated with the help of perlbug 1.35 running under perl v5.8.7.
> >>>
> >>>
> >>>-----------------------------------------------------------------
> >>>
> >>>It seems that perldoc creates temporary files in \WINDOWS\TEMP,
> >>>but doesn't delete them upon exit.
> >>
> >>This is not a bug.
> >
> >
> > Actually it IS a bug. Even if its a known bug deliberately left in place.
>
> Actually, it is not. It is explicitly planned & coded behaviour. ;)
Ok, ok, its a bug^Wfeature. :-)
> It may not be the preferred solution, but it is apparent that a choice
> was made and that the code behaves as it was intended.
As Vadim says, its a design bug, not an implementation bug. But IMO
its still a bug. Or at the very least its a nasty kludge.
> >>I don't recall the specific reason, but temp files
> >>are kept for a period of time. I think it has something to do with the
> >>file locking semantics of the temp files created under Windows such that
> >>they can't be unlinked under certain conditions, but my memory is known
> >>to be quite faulty and occasionally makes up stuff.
> >
> >
> > This only holds true for files opened using "normal" perl file opening
> > mechanisms as the unixy style file opens dont allow for Win32 users to
> > exploit Win32 specific mechanisms for achieving this.
> >
> > use Win32API::File;
> >
> > $hTemp= createFile( "$ENV{Temp}/temp.$$", "wn", "",
> > { Attributes=>"hst", Flags=>FILE_FLAG_DELETE_ON_CLOSE() } )
> > or die "Can't create temporary file, temp.$$: $^E\n";
> >
> > will create a file that is marked as temporary and which will be
> > automatically deleted when the handle is closed. Marking it as a
> > temporary file means that if at all possible the OS will keep the
> > entire file in cache and avoid writing it to disk, meaning that using
> > the file is more efficient.
>
> Hmm, my previous explanation as to why temp files are not immediately
> deleted may have been misleading (or just wrong).
You can't unlink an open file under normal cicrumstances. You can
open a file with the FILE_SHARE_DELETE which will allow a second
process to open the file with DELETE permissions, but i dont think the
file can actually be deleted until the deleting process is the only
one with a handle to the object. Although having said that the MSDN
docs do suggest that it is possible to delete an open object, I just
havent put together a test case that proves it, instead the test cases
I have tried suggest the opposite. Go figure. :-)
Relevent links:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createfile.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/creating_and_opening_files.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_security_and_access_rights.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/standard_access_rights.asp
>It's more likely the external pager that doesn't properly release the
file. Again, this is
> based on vague memories of this being discussed quite a while back, so I
> may be in error on the specifics.
> Although, I do believe the basic
> problem is related to files being locked so that they cannot be
> unlinked. Anyone who has had to spend any time on Windows has likely run
> into those annoying files that cannot be deleted even though that file
> is not currently open by any running application.
Are you sure the file isnt open by a running application? Every time
ive encountered this problem a search with tools from
sysyinternals.com shows that some application or another actually does
have the file open. More commonly however you see directories that
cant be deleted because they are the CWD of some running task, which
is much harder to track down.
Cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
