Forum: Ruby Re: Atomic File.copy from Linux to Windows shared drive

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Berger, Daniel (Guest)
on 2006-05-24 01:27
(Received via mailing list)
> >
> > 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 communication is the property of Qwest and may contain confidential
or
privileged information. Unauthorized use of this communication is
strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and
destroy
all copies of the communication and any attachments.
unknown (Guest)
on 2006-05-24 02:01
(Received via mailing list)
On Wed, 24 May 2006, Berger, Daniel wrote:

>>>
>>> The problem is that File.rename is raising Errno::EXDEV errors, and
>
> 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.

cheers.

-a
Leslie V. (Guest)
on 2006-05-24 02:36
(Received via mailing list)
On 5/23/06, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> >>> require 'ftools'
> >>> 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.
Daniel B. (Guest)
on 2006-05-24 04:37
(Received via mailing list)
removed_email_address@domain.invalid wrote:
>>>> require 'ftools'
>>>> end
>>
> 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
This topic is locked and can not be replied to.