httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Wichitill <ma...@gmx.de>
Subject Re: [apreq-2] Open upload with or without :APR
Date Thu, 22 Jul 2004 17:52:26 GMT
Joe Schaefer wrote:
> Markus Wichitill <mawic@gmx.de> writes:
>>Regarding the last chunk: for the link test in request.pm to succeed,
>>I didn't actually need the :APR on Win32, unlike for the link test in
>>upload.pm. I'm not sure why, but I guess using the same code can't hurt.
> 
> Probably because link()ed files don't need to SHARE_DELETE,
> since only the temp file is actually scheduled for deletion.

But the link test in upload.pm does need the :APR open in my case, since 
otherwise opening the file will fail with "permission denied". That's what I 
reported in my various issues thread.

SysInternals FileMon is more specific and reports a "SHARING VIOLATION":

Apache.exe:1548  OPEN  C:\DOKUME~1\mawic\Temp\apreqK3PHF7  SUCCESS  Options: 
Open  Access: All
Apache.exe:1548  QUERY INFORMATION  C:\DOKUME~1\mawic\Temp\apreqK3PHF7 
SUCCESS  Attributes: A
Apache.exe:1548  OPEN  C:\DOKUME~1\mawic\Temp\linkfile  SUCCESS  Options: 
Open  Access: All
Apache.exe:1548  SET INFORMATION   C:\DOKUME~1\mawic\Temp\apreqK3PHF7 
SUCCESS  FileLinkInformation
Apache.exe:1548  CLOSE  C:\DOKUME~1\mawic\Temp\linkfile  SUCCESS
Apache.exe:1548  CLOSE  C:\DOKUME~1\mawic\Temp\apreqK3PHF7  SUCCESS
Apache.exe:1548  OPEN  C:\DOKUME~1\mawic\Temp\linkfile  SHARING VIOLATION 
Options: Open  Access: All

The "SET INFORMATION FileLinkInformation" line confirms that a real NTFS 
hardlink is created, and not a copy.

Randy, can you confirm that the upload.pm link test doesn't need :APR in 
your case because $upload->link creates a copy for you?

What still somewhat confuses me is that I get this sharing violation, 
whereas Randy's non-APR opening of the original tempfile nukes it, according 
to his old thread. Of course that might just be the difference between 
original hardlink and new hardlink.

>>Of course it's still not possible to simply pass $upload->tempname to
>>someone's Perl module or external program (which is was what the
>>person that requested tempname on the mp list wanted) and be
>>Win32-compatible. 
> 
> We're about as close (with your patch, e.g.) as we can reasonably go with 
> this, IMO.  We want to allow folks to pass the name to an external app for 
> processing, but it's not our problem if *that* app has trouble
> opening the file. 

Well, we effectively lock the file by using those special file flags.

 > We just need to remind module authors about the
> usefulness of link() in this context,

Unless I'm completely wrong with my diagnosis above, link isn't more useful 
than tempname in this context.

> and that fh() (or better io()), 
> also work as documented on all supported platforms.  If so, we really 
> just need fh() to use "<:APR" on Win32, and document that fh() requires
> 5.8 on Windows.

mod_perl 2.0 already requires Perl 5.8 on Windows because of the threading, 
so this would only be relevant for CGI I guess. However what needs to be 
documented is that on Windows:

- $upload->tempname requires :APR

- Hardlinks created by $upload->link require :APR when they're opened during 
the same request (unless they're created on a different partition or on a 
FAT partition)

- If the user wants to pass a filename to an external program, he has to 
create a copy of the upload data by writing $upload->bb or $upload->io to a 
new file

All in all, this is so ugly and confusing that I still think that 
explicitely deleting the tempfile with a cleanup handler without using 
special Win32 flags would be the simplest solution, especially if that's 
what APR already does on Unix. The occasional leftover tempfile can be 
cleaned up by a cronjob, and there are simpler DoS attacks than uploading 
files while hoping that enough of them stick around because of segfaults etc 
to fill a modern HD.

Mime
View raw message