> > > > 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 2006-05-23 23:27
on 2006-05-24 00:01
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 2006-05-24 00:36
On 5/23/06, firstname.lastname@example.org <email@example.com> 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.
on 2006-05-24 02:37
firstname.lastname@example.org 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