develooper Front page | perl.perl5.porters | Postings from October 2005

Re: Inconsistent behaviour when removing files on Cygwin

Thread Previous | Thread Next
From:
demerphq
Date:
October 27, 2005 01:48
Subject:
Re: Inconsistent behaviour when removing files on Cygwin
Message ID:
9b18b3110510270147q229584e9ve716cf6968b84a5@mail.gmail.com
On 10/27/05, Yitzchak Scott-Thoennes <sthoenna@efn.org> wrote:
> On Thu, Oct 27, 2005 at 09:19:32AM +0200, demerphq wrote:
> > On 10/27/05, Yitzchak Scott-Thoennes <sthoenna@efn.org> wrote:
> > > On Wed, Oct 26, 2005 at 05:28:30PM +0200, S?bastien Aperghis-Tramoni wrote:
> > > > Hello,
> > > >
> > > > While correcting a bug in Net::Pcap Makefile.PL with a Windows developer,
> > > > we stumbled upon the strange behaviour of the unlink() function under
> > > > Cygwin. It looks like it tries to emulates the Unix behaviour but fails
> > > > to achieve it.
> > >  ...
> > > > Ok, the equivalent program in C produces the same results, so the error is
> > > > likely to be inside Cygwin API, but shouldn't this be documented somewhere?
> > > > Maybe in perlport/"DOS and Derivatives"?
> > >
> > > perlport says it short and sweet: (implied: For portable code:) "Don't
> > > C<unlink> or C<rename> an open file."  I don't think repeating that in
> > > a dosish section would be more helpful.
> > >
> > > cygwin may defer unlinks until the file is closed or until the process
> > > ends.  Exactly what it does depends on the exact flavor of windows and
> > > how reliable (cygwin thinks) the relevant win32 api calls are there.
> >
> > Actually, afaiui its not a "may" its a "must". The Win32 API doesnt
> > support unlink directly.
>
> I'd heard a rumor there was a way of opening a file that allowed
> it to be unlinked before close, hence the may.
>
> > The way you delete a file in Win32 is you use CreateFile with the
> > DELETE_ON_CLOSE flag. When you close the file it is either marked as
> > "Pending Delete" (if other processes also have the file open) or it is
> > outright deleted (if no other processes have the file open).
> > (See references below, this is better explained in the last posting on
> > the last url in my reference list)
> >
> > The Win32 C Libraries provide _unlink and _wunlink for compatibility
> > purposes, but they just do what is described above.

As does DeleteFile() which is used in the code you posted...

From MSDN

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/deletefile.asp

"The DeleteFile function marks a file for deletion on close.
Therefore, the file deletion does not occur until the last handle to
the file is closed. Subsequent calls to CreateFile to open the file
fail with ERROR_ACCESS_DENIED."


> Reminds me of the Win32/cygwin difference in handling perl -i with
> no suffix specified; cygwin makes a shot at allowing at unix-assuming
> code to run, while Win32 forces a change, but has no surprising edge
> cases.

I guess the way to make all Win32 api using code (ie cygwin or not)
consistent in least surprising way would be always open their files
without FILE_SHARE_DELETE.

There must be some way for a cygwin program to do that....

cheers,
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About