Nation, Carey
3/19/2008 6:23:00 PM
That works and the performance is good. Two caveats. First, in the =
CreateFile, it wants 0 rather than nil. Second, CloseHandle isn't =
implemented in windows/file.rb, so I added it to my local copy. This is =
actually a really big oversight since leaving handles of any kind open =
in win32 is a big leak problem. =20
Thanks!
-----Original Message-----
From: Daniel Berger [mailto:djberg96@gmail.com]=20
Sent: Tuesday, March 18, 2008 6:45 PM
To: ruby-talk ML
Subject: Re: win32 File.size slow?
On Mar 18, 12:56=A0pm, "Nation, Carey" <Carey.Nat...@turner.com> wrote:
> Last week I posted a question about incorrect file sizes coming back
> incorrectly from File.size? for really large files. =A0I changed my =
script
> to use the win32 version, which returns the correct sizes, and now the
> script is unacceptably slow. The bottleneck is the File.size call. My
> scripts startup went from about a minute to, well I don't know because
> it's never finished. =A0I'm walking a file path that is somewhat =
indirect,
> but the other file operations perform well. =A0I'm reading files, =
using
> UNC paths, through samba on linux boxes that mount a giant file system
> through fiber.
That's interesting. The File.size method is really a wrapper for
File::Stat#size, which uses stat64() to stat the file in question. I
wonder if it's choking on the Samba/UNC path. Wouldn't be the first
app to do so.
What happens if you replace File.size in lib/win32/file.rb with this
version:
# Untested
class << self
def size(file)
handle =3D CreateFile(
file,
GENERIC_READ,
FILE_SHARE_READ,
nil,
OPEN_EXISTING,
FILE_FLAG_OVERLAPPED | FILE_FLAG_NO_BUFFERING,
nil
)
if handle =3D=3D INVALID_HANDLE_VALUE
raise Error, get_last_error
end
file_size =3D [0].pack('Q')
GetFileSizeEx(handle, file_size)
file_size =3D file_size.unpack('Q')[0]
unless CloseHandle(handle)
raise Error, get_last_error
end
file_size
end
end