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.
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
On 5/23/06, [email protected] [email protected] 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.
[email protected] 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