From: Leslie Viljoen <leslieviljoen@...>
Date: 2006-05-24T07:35:00+09:00
Subject: Re: Atomic File.copy from Linux to Windows shared drive

On 5/23/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> On Wed, 24 May 2006, Berger, Daniel wrote:
>
> >> -----Original Message-----
> >> From: frank.cameron@gmail.com
> >> [mailto:frank.cameron@gmail.com] On Behalf Of brabuhr@gmail.com
> >> Sent: Tuesday, May 23, 2006 3:18 PM
> >> To: ruby-talk ML
> >> Subject: Re: Atomic File.copy from Linux to Windows shared drive
> >>
> >>
> >>> require 'ftools'
> >>> require 'timeout'
> >>>
> >>> begin
> >>>    Timeout.timeout(3){
> >>>       File.copy('temp.txt', 'temp.bak')
> >>>       File.rename('temp.bak', '/X/temp.txt')
> >>>       File.unlink('temp.bak')
> >>>    }
> >>> rescue Errno::EPERM
> >>>    # Ignore bogus EPERM errors - harmless
> >>> end
> >>>
> >>> The problem is that File.rename is raising Errno::EXDEV errors, and
> >>> simply ignoring those won't work.
> >>
> >> Shouldn't it be:
> >>   File.copy('temp.txt', '/X/temp.bak')
> >>   File.rename('/X/temp.bak', '/X/temp.txt')
> >
> > Whoops! Yeah, that worked.  I still don't know what will happen if the
> > share goes down, though.

You may need some way of checking the files on the other side to see
if they check out. If not, try and get the report generator to copy
them again.

You could write a small Ruby script on the report-sending side that
makes an MD5 sum and puts in a "latest.md5" file, here's some help:

require 'md5'
puts MD5.new(File.open('filename', 'rb').read).hexdigest

Then you'd need a script on the other side to pick up the latest file,
make sure the date is right and check the MD5 sum to be sure the
report is intact. If not, signal the report writer to recopy and then
check again in a a few minutes. When everything checks out, run the
report reader program.

Oh, I just noticed that the server is not available to you. Never mind then.