From: Daniel Berger <djberg96@...>
Date: 2006-05-24T09:36:34+09:00
Subject: Re: Atomic File.copy from Linux to Windows shared drive

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.
>>
>> Regards,
>>
>> Dan
> 
> this __should__ depend on how the drive is mounted.  for instance, with an
> nfs 'hard' mount your script would hang until the remote server came 
> back up -
> and then proceed.  as amazing as this sounds it routinely works for us 
> with 30
> nodes hits giant nfs mounted raids.  i assume there are similar options for
> mounting windows shared drives but you'll have to consult the docs for 
> that...
> in any case you are looking for something like 'hard' mount.

Unfortunately I know very little about the setup, so I'm not sure what 
I'm dealing with.

However, after I wrote that I noticed something odd.  The File.copy from 
ftools was sometimes failing, even when there didn't appear to be a 
problem with the shared drive!  I was getting partial copies, or copies 
that appeared to be intact but had slightly different file sizes.

I switched to FileUtils.cp and things seem to work much better.  I 
haven't dug into the implementations too much, so I'm curious as to why 
that might be.

Anyway, between that and a timeout wrapper, I'm hoping to catch the next 
failure.

Thanks,

Dan