[vlc-devel] [PATCH 3/3] Added livehttp access_out module to support HTTP Live Streaming

[Keary Griffin]

I was putting this together today to submit, and I still have one issue 
with regards to vlc_rename and win32.

There was a patch committed to libvlc earlier this month which I thought 
would make the Win32 issue with vlc_rename better for livehttp  (By 
attempting to delete the file and then perform the rename if the initial 
rename failed).  With this patch livehttp would mostly work on win32, 
but without it livehttp wouldn't really work at all. (Since the playlist 
file would never get updated after it was written once).

The patch is git commit 5581a1ec59bde33d52713f232620777b3c62628d:
" Win32: vlc_rename() needs to erase target file first, fixes #3521"

The problem I'm having is that the fix doesn't seem to work as intended 
for me, at least when I compile a win32 version of VLC.  I am 
cross-compiling it using mingw32 4.2.1-sjlj, using 
contrib-20100504-win32-bin-gcc-4.4.2-runtime-3.17-only.tar.bz2  under 
Ubuntu 10.04.

The patch is as follows:

     if (_wrename (wold, wnew) && errno == EACCES)
     {   /* Windows does not allow atomic file replacement */
         if (_wremove (wnew))
         {
             errno = EACCES; /* restore errno */
             return -1;
         }
         if (_wrename (wold, wnew))
             return -1;
     }

However when I add debugging and compile VLC for win32, it appears 
wrename is setting errno to  EEXISTS, not EACCES when the file already 
exists, so the code to remove the existing file and rename never gets 
executed.  I'm running Win32 Vista (under VirtualBox).

I'm not sure what the official method to compile VLC for win32 is, and 
I'm not setup to test it using a MSYS/win32 native build, so I'm not 
sure if the build method is causing the issue or not.

Should I just ignore this issue (as it is possible it is only me who is 
having it, and even if it is not it is a seperate issue), and just 
submit the livehttp patch?

Thanks
Keary


On 05/23/2010 12:41 PM, Ilkka Ollakka wrote:
> Hi,
>
> As it's been somewhat quiet with this patch regarding rejecting it. I'm
> ok to merge it in without those win32-file thinggies, as it seems to be
> the point that people have opinions and no clear agreement. It seems to
> be iffy on working in windows anyway on file-accessing point of view
> with any of those methods ?
>
> So if you could send new patch without those ifdef WIN32 stuff ?
>
> On Mon, May 10, 2010 at 06:52:53PM +0300, Ilkka Ollakka wrote:
>    
>> On Tue, Mar 30, 2010 at 11:00:32PM -0400, Keary Griffin wrote:
>>      
>    
>>> +#ifdef WIN32
>>> +static int convert_path ( const char *restrict path, wchar_t *restrict wpath )
>>> +static int win32_replace_rename ( const char *oldpath, const char *newpath )
>>> +static int win32_retry_rename( const char *oldpath, const char *newpath )
>>>        
>    
>> Maybe these should be in core instead access_output ? seems kinda
>> generic functions. Didn't check if courmisch allready merged them in.
>>      
>    
>>> +    if ( p_sys->i_numsegs == 0 )
>>> +        i_firstseg = 1;
>>> +    else
>>> +        i_firstseg = ( p_sys->i_segment>= p_sys->i_numsegs ) ? ( ( p_sys->i_segment - p_sys->i_numsegs ) + 1 ) : 1;
>>>        
>    
>> Wouldn't this be simpler if you just extend first if to check if
>> i_segments<  i_umsegs too?
>>      
>>
>>
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> http://mailman.videolan.org/listinfo/vlc-devel
>>      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20100525/f1b3ca2a/attachment.html>