FW: 2.8.10, OSX 10.5.8, Xcode 3.1.3 ::wxRenameFile behaviour issues

[Neil Ward]

Hello

I have written a hot folder function making use of the
wxDir::GetAllFiles to build a files list and then the::wxRenameFile
function to move the files once detected. The issue is that if a large
file is copied into the watch folder the wxDir::GetAllFiles function
returns the file name prior to completion of the copy.
The ::wxRenameFile then fails to correctly move the file, but does not
return false.

I have tried to test the file with wxFileName::IsOk,
wxFileName::IsFileWritable and even wxFileName::Touch thinking that
these would fail whilst the file is still opened by the Finder, but
they all return true.

Can anyone recommend an alternative solution?

Thanks

Neil

[Vadim Zeitlin]

On Fri, 30 Oct 2009 10:20:32 -0700 (PDT) Neil Ward <nw...@colourconfidence.com> wrote:

NW> I have written a hot folder function making use of the
NW> wxDir::GetAllFiles to build a files list and then the::wxRenameFile
NW> function to move the files once detected. The issue is that if a large
NW> file is copied into the watch folder the wxDir::GetAllFiles function
NW> returns the file name prior to completion of the copy.
NW> The ::wxRenameFile then fails to correctly move the file, but does not
NW> return false.

I don't see why could this happen from reading the code. I do see that
wxRenameFile() ends up by calling wrename() in Unicode build and as we had
problems with wide char APIs under OS X in the past I wonder if wrename()
could misbehave there. Can you test if it works correctly on your system?

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Stefan Csomor]

Hi

one idea might be to recheck the file-size after an arbitrary delay and if
the size hasn't changed, you could assume the copying/upload or whatever is
done

just my 0.02$

Best,

Stefan

[Neil Ward]

Hi

I tried Stefan's suggestion of periodically checking the file size,
but the Finder tends to write in fairly large blocks, which makes
monitoring difficult and probably platform dependant. Thank you for
the suggestion anyway.

After completing a little further research it seems that the Finder
opens the copy file locked i.e. with the LOCK_NB flag set. I have
tried to find an option within wxWidgets to detect the file status but
couldn't find one. I have therefore written a quick test function,
which seems to work. I thought I would include it just in case anyone
else hits the same problem. Please note this has only been tested on
OSX and the function requires write permission enabled for the file to
be correctly tested.

Thanks

Neil

bool IsFileLocked( const wxString &aFile )
{
bool isLocked = false;

int anFD = open( aFile.c_str(), O_WRONLY, S_IRUSR | S_IWUSR );
if ( anFD != -1 )
{
isLocked = ( flock( anFD, LOCK_EX | LOCK_NB ) < 0 );
if( !isLocked )
flock( anFD, LOCK_UN );

close( anFD );
}

return isLocked;