From Daniel.Berger at qwest.com Fri Aug 1 11:05:18 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 1 Aug 2008 10:05:18 -0500 Subject: [Win32utils-devel] Plan to merge win32-file and win32-file-stat Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D341C@ITOMAE2KM01.AD.QINTRA.COM> Hi everyone, Just wanted to let you know that, after a hair pulling experience with win32-file and win32-file-stat, I'm eventually going to merge the latter into the former (i.e. stat.rb will be merged into the win32-file library). It's just too easy to make a change in one that causes a problem in the other. By merging them into a single library I can make sure they're tested together, too. This should also help reduce the chance of someone accidentally require'ing win32-file-stat separately. Thanks, 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. From Daniel.Berger at qwest.com Mon Aug 18 09:56:46 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Mon, 18 Aug 2008 08:56:46 -0500 Subject: [Win32utils-devel] Playing with NtQueryInformationFile In-Reply-To: <200808180625.m7I6PjLk003393@wolfram.com> References: <200808180625.m7I6PjLk003393@wolfram.com> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514C52@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: dlibrik at wolfram.com [mailto:dlibrik at wolfram.com] > Sent: Monday, August 18, 2008 12:26 AM > To: Berger, Daniel > Subject: Re: [Win32utils-devel] Playing with NtQueryInformationFile > > Hello Daniel, > > I apologize for writing to you out of nowhere, but you posted > on the Ruby Win32utils-devel list a while back and I think > you might have the answer to a question I'm working on. Hi David, No problem. I've cc'd the win32utils-devel list for future Googlers. Hope that's ok. > You wrote: > > I'm trying to get the allocation size of a file via a file handle > > (rather than its name). The example below works for > > FileNameInformation but I can't get it to work as expected > for FileStandardInformation. > > > > I'm trying to get File::Stat#blksize working. It's easy > enough when I > > have the file _name_, but I'd like to get it from the file > _handle_ so > > I can make it work properly. > > I'm looking for the allocation size of a file given its name, > actually. > What "easy enough" solution am I blindly missing? Use GetDiskFreeSpace, then multiply the sectors by the bytes. My email is a bit misleading, since it's not really the file name itself that matters, but the root path of the file, since all files on the same filesystem have the same blocksize. For relative paths, just pass nil as the file name, and it will default to your system's root path. A pretty good guess is 4096, since that's the default on the vast majority of Windows systems. The ones I've come across anyway. Here's some sample code using windows-pr: require 'windows/filesystem' require 'windows/path' include Windows::FileSystem include Windows::Path file = "C:\\test.txt" sectors = [0].pack('L') bytes = [0].pack('L') free = [0].pack('L') total = [0].pack('L') if PathStripToRoot(file) file += "\\" unless file[-1].chr == "\\" # Add a trailing slash else file = nil # Default to relative root path end if GetDiskFreeSpace(file, sectors, bytes, free, total) size = sectors.unpack('L').first * bytes.unpack('L').first else size = "Unknown" end puts "Size: #{size}" 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. From djberg96 at gmail.com Sat Aug 23 20:43:35 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 23 Aug 2008 18:43:35 -0600 Subject: [Win32utils-devel] Potential win32-process patch Message-ID: <48B0AEB7.3060309@gmail.com> Hi all, Just going over win32-process, and I saw a few opportunities to refactor the kill method. In summary, signals 2 and 3 now raise an error if they fail, no handle is opened in the case of signals 2 and 3, and each of the kill approaches is now wrapped in a RUBY_CRITICAL section, which more closely mimics MRI. How does this patch look? Thanks, Dan >diff -u process.rb process.new --- process.rb Sat Aug 23 18:38:00 2008 +++ process.new Sat Aug 23 18:39:06 2008 @@ -155,71 +155,89 @@ pid = Process.pid end - # No need for full access if the signal is zero - if signal == 0 - access = PROCESS_QUERY_INFORMATION|PROCESS_VM_READ - handle = OpenProcess(access, 0 , pid) - else - handle = OpenProcess(PROCESS_ALL_ACCESS, 0, pid) - end - case signal when 0 - if handle != 0 - killed_pids.push(pid) - CloseHandle(handle) - else - # If ERROR_ACCESS_DENIED is returned, we know it's running - if GetLastError() == ERROR_ACCESS_DENIED + RUBY_CRITICAL{ + access = PROCESS_QUERY_INFORMATION | PROCESS_VM_READ + handle = OpenProcess(access, 0 , pid) + + if handle != 0 killed_pids.push(pid) + CloseHandle(handle) else - raise Error, get_last_error + # If ERROR_ACCESS_DENIED is returned, we know it's running + if GetLastError() == ERROR_ACCESS_DENIED + killed_pids.push(pid) + else + raise Error, get_last_error + end end - end + } when 2 - if GenerateConsoleCtrlEvent(CTRL_C_EVENT, pid) - killed_pids.push(pid) - end + RUBY_CRITICAL{ + if GenerateConsoleCtrlEvent(CTRL_C_EVENT, pid) + killed_pids.push(pid) + else + raise Error, get_last_error + end + } when 3 - if GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, pid) - killed_pids.push(pid) - end + RUBY_CRITICAL{ + if GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, pid) + killed_pids.push(pid) + else + raise Error, get_last_error + end + } when 9 - if TerminateProcess(handle, pid) - CloseHandle(handle) - killed_pids.push(pid) - @child_pids.delete(pid) - else - raise Error, get_last_error - end + RUBY_CRITICAL{ + handle = OpenProcess(PROCESS_TERMINATE, 0, pid) + + if handle == 0 + raise Error, get_last_error + end + + if TerminateProcess(handle, pid) + CloseHandle(handle) + killed_pids.push(pid) + @child_pids.delete(pid) + else + raise Error, get_last_error + end + } else - if handle != 0 - thread_id = [0].pack('L') - dll = 'kernel32' - eproc = 'ExitProcess' + RUBY_CRITICAL{ + handle = OpenProcess(PROCESS_ALL_ACCESS, 0, pid) + + if handle != 0 + thread_id = [0].pack('L') + dll = 'kernel32' + eproc = 'ExitProcess' - thread = CreateRemoteThread( - handle, - 0, - 0, - GetProcAddress(GetModuleHandle(dll), eproc), - 0, - 0, - thread_id - ) + thread = CreateRemoteThread( + handle, + 0, + 0, + GetProcAddress(GetModuleHandle(dll), eproc), + 0, + 0, + thread_id + ) - if thread - WaitForSingleObject(thread, 5) - CloseHandle(handle) - killed_pids.push(pid) - @child_pids.delete(pid) + if thread + WaitForSingleObject(thread, 5) + CloseHandle(handle) + killed_pids.push(pid) + @child_pids.delete(pid) + else + CloseHandle(handle) + raise Error, get_last_error + end else - CloseHandle(handle) raise Error, get_last_error end - else - raise Error, get_last_error - end + } + @child_pids.delete(pid) end } @@ -613,8 +631,7 @@ begin unless Process32First(handle, proc_entry) - error = get_last_error - raise Error, error + raise Error, get_last_error end while Process32Next(handle, proc_entry) @@ -697,4 +714,4 @@ def fork(&block) Process.fork(&block) end From noreply at rubyforge.org Fri Aug 29 08:11:09 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 29 Aug 2008 08:11:09 -0400 (EDT) Subject: [Win32utils-devel] [ win32utils-Bugs-21726 ] Description not shown on Win2k3-x64 Message-ID: <20080829121110.09562185859A@rubyforge.org> Bugs item #21726, was opened at 2008-08-29 14:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=21726&group_id=85 Category: win32-eventlog Group: Code Status: Open Resolution: None Priority: 3 Submitted By: Damjan Rems (ther) Assigned to: Nobody (None) Summary: Description not shown on Win2k3-x64 Initial Comment: I have only one 64bit server so I cannot commit if the same error was also present before or is consistant. Win2k3 R2 Standard x64: # # Another machine Win2k3 R2 Standard 32 bit: # # by TheR ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=21726&group_id=85