Hi all,
I committed win32-driveinfo 0.1.0 to CVS.
What is it?
========== A class for getting information of drives
Synopsis
======= include Win32::DriveInfo
(sectorsPerCluster,
bytesPerSector,
numberOfFreeClusters,
totalNumberOfClusters,
freeBytesAvailableToCaller,
totalNumberOfBytes,
totalNumberOfFreeBytes) = getDriveSpace(''c'').to_a
totalNumberOfFreeBytes =
getDriveSpace(''c'').TotalNumberOfFreeBytes
totalNumberOfBytes =
getDriveSpace("\\\\serv\\share").TotalNumberOfBytes
drives = getDrivesInUse()
freelet = getFreeDriveLetters()
drivetype = getDriveType(''a'')
(volumeName,
volumeSerialNumber,
maximumComponentLength,
fileSystemName, attr) = getVolumeInfo(''g'').to_a
(majorVersion, minorVersion, buildNumber,
platformId, buildStr) = getVersionEx().to_a
# check is your CD-ROM loaded
aCDROM = getDrivesInUse().select {|x| getDriveType(x) == "CDROM"
}[0]
aCD_inside = isReady(aCDROM)
Constants
========DriveInfo::VERSION
The current version of this package.
DriveInfo::FS_CASE_IS_PRESERVED
DriveInfo::FS_CASE_SENSITIVE
DriveInfo::FS_UNICODE_STORED_ON_DISK
DriveInfo::FS_PERSISTENT_ACLS
DriveInfo::FS_VOL_IS_COMPRESSED
DriveInfo::FS_FILE_COMPRESSION
Module Methods
====DriveInfo#getDriveSpace( drive )
Returns a structure that contains drivespace information such as
SectorsPerCluster, BytesPerSector, NumberOfFreeClusters,TotalNumberOfClusters
and FreeBytesAvailable, :TotalNumberOfBytes, :TotalNumberOfFreeBytes
drive is drive-letter in either ''c'' or
''c:'' or ''c:\\'' form or UNC path
in either "\\\\server\\share" or
"\\\\server\\share\\" form.
DriveInfo#getDrivesInUse()
Returns sorted array of all drive-letters in use.
DriveInfo#getFreeDriveLetters()
Returns sorted array of all drive-letters that are available for allocation.
DriveInfo#getDriveType(drive)
Returns string value:
"unknown" - the drive type cannot be determined.
"no root dir" - the root directory does not exist.
"Removable" - the drive can be removed from the drive
(removable).
"Fixed" - the disk cannot be removed from the drive
(fixed).
"Remote" - the drive is a remote (network) drive.
"CDROM" - the drive is a CD-ROM drive.
"RAM" - the drive is a RAM disk.
drive is drive-letter in either ''c'' or
''c:'' or ''c:\\'' form or UNC path
in either "\\\\server\\share" or
"\\\\server\\share\\" form.
DriveInfo#isReady(drive)
Returns TRUE if root of the drive is accessible, otherwise FALSE.
This one isn''t really something cool - the function just tries to
chdir to the drive''s root. This takes time and produces unpleasant
sound in case the removable drive is not loaded. If somebody knows
some better way to determine is there something inside your CD-ROM
or FDD - please let me know (in fact CD-ROMs, RAM drives and network
drives return their status fast,
may be some other devices make problem, dunno).
drive is drive-letter in either ''c'' or
''c:'' or ''c:\\'' form or UNC path
in either "\\\\server\\share" or
"\\\\server\\share\\" form.
DriveInfo#getVolumeInfo(drive)
Returns a structure that contains Volume information such as
VolumeName - name of the specified volume.
VolumeSerialNumber - volume serial number.
MaximumComponentLength -
filename component supported by the specified file system.
A filename component is that portion of a filename between backslashes.
Indicate that long names are supported by the specified file system.
For a FAT file system supporting long names, the function stores
the value 255, rather than the previous 8.3 indicator. Long names can
also be supported on systems that use the New Technology file system
(NTFS).
FileSystemName - name of the file system (such as FAT, FAT32, CDFS or
NTFS).
attr - array of constants
FS_CASE_IS_PRESERVED - file system preserves the case of filenames
FS_CASE_SENSITIVE - file system supports case-sensitive filenames
FS_UNICODE_STORED_ON_DISK - file system supports Unicode in filenames as
they appear on disk
FS_PERSISTENT_ACLS - file system preserves and enforces ACLs
(access-control lists).
For example, NTFS preserves and enforces ACLs, and FAT does not.
FS_VOL_IS_COMPRESSED - file system supports file-based compression
FS_FILE_COMPRESSION - specified volume is a compressed volume; for ex., a
DoubleSpace volume
drive is drive-letter in either ''c'' or
''c:'' or ''c:\\'' form.
DriveInfo#getVersionEx(drive)
Returns a structure that contains Version information such as
MajorVersion - major version number of the operating system. For Windows NT
version 3.51, it''s 3; for Windows NT version 4.0,
it''s 4; for Windows XP, Windows 2000 and
Windows 2003, it''s 5.
MinorVersion - minor version number of the operating system. For Windows NT
version 3.51, it''s 51; for Windows NT version 4.0,
it''s 0.
BuildNumber - build number of the operating system.
PlatformId - 0 for Win32s, 1 for Win95/98, 2 for Win NT
BuildStr - Windows NT: Contains string, such as "Service Pack
3".
Indicates the latest Service Pack installed on the system.
If no Service Pack has been installed, the string is empty.
Windows 95: Contains a null-terminated string that provides
arbitrary additional information about the operating system.
It is pure ruby implementation using Ruby/dl.
Regards,
Park Heesob
Hi Heesob, I have a couple problems with this. First, I guess I didn''t tell you, but I''m opposed to using Ruby/DL for any of our packages. It''s just not stable, and has 64-bit issues that are effectively unresolvable. This could be a problem very soon with 64-bit Windows on the horizon. You can read about Jamis Buck''s negative experience with Ruby/DL at http://www.jamisbuck.org/jamis/blog.cgi/programming/ruby/Disappointments %20in%20Ruby%20Land_20041230165456.tx Contrary to whatever Matz has said about Win32API being deprecated, I am officially declaring Ruby/DL dead for Win32Utils development and Win32API to be the preferred choice for any pure Ruby development. If the Win32API package is ever removed from core Ruby, I will fork Ruby. This is not an attack on you Heesob. I should have mentioned this on the list sooner, so it''s my fault. I hedged for a while on the issue because I wasn''t sure what the future held with regards to Win32API vs. Ruby/DL. Now that Ruby/DL has proven to be unreliable, I can be more confident in sticking with Win32API. That being said, I won''t force you to rewrite it. Just keep in mind that all bugs, feature requests, etc, will be directed to *you*. :) Second, I was hoping to keep the API similar to Mike Hall''s "filesystem" package. Did you determine that it just wasn''t feasible? I made a comment about it on the Feature Request. If we can''t make it compatible, that''s fine, but I thought we should at least try. Regards, Dan> -----Original Message----- > From: win32utils-devel-bounces@rubyforge.org > [mailto:win32utils-devel-bounces@rubyforge.org] On Behalf Of > Park Heesob > Sent: Sunday, February 06, 2005 11:08 PM > To: win32utils-devel@rubyforge.org > Subject: [Win32utils-devel] [ANN] win32-driveinfo in CVS > > > Hi all, > > I committed win32-driveinfo 0.1.0 to CVS. > > What is it? > ==========> A class for getting information of drives > > Synopsis > =======> include Win32::DriveInfo > > (sectorsPerCluster, > bytesPerSector, > numberOfFreeClusters, > totalNumberOfClusters, > freeBytesAvailableToCaller, > totalNumberOfBytes, > totalNumberOfFreeBytes) = getDriveSpace(''c'').to_a > > totalNumberOfFreeBytes = > getDriveSpace(''c'').TotalNumberOfFreeBytes > > totalNumberOfBytes = > getDriveSpace("\\\\serv\\share").TotalNumberOfBytes > > drives = getDrivesInUse() > > freelet = getFreeDriveLetters() > > drivetype = getDriveType(''a'') > > > (volumeName, > volumeSerialNumber, > maximumComponentLength, > fileSystemName, attr) = getVolumeInfo(''g'').to_a > > > (majorVersion, minorVersion, buildNumber, > platformId, buildStr) = getVersionEx().to_a > > # check is your CD-ROM loaded > aCDROM = getDrivesInUse().select {|x| getDriveType(x) == > "CDROM" }[0] > > aCD_inside = isReady(aCDROM) > > Constants > ========> DriveInfo::VERSION > The current version of this package. > DriveInfo::FS_CASE_IS_PRESERVED > DriveInfo::FS_CASE_SENSITIVE > DriveInfo::FS_UNICODE_STORED_ON_DISK > DriveInfo::FS_PERSISTENT_ACLS > DriveInfo::FS_VOL_IS_COMPRESSED > DriveInfo::FS_FILE_COMPRESSION > > Module Methods > ====> DriveInfo#getDriveSpace( drive ) > Returns a structure that contains drivespace information > such as SectorsPerCluster, BytesPerSector, > NumberOfFreeClusters,TotalNumberOfClusters > and FreeBytesAvailable, :TotalNumberOfBytes, > :TotalNumberOfFreeBytes > drive is drive-letter in either ''c'' or ''c:'' or ''c:\\'' form > or UNC path > in either "\\\\server\\share" or > "\\\\server\\share\\" form. > > DriveInfo#getDrivesInUse() > Returns sorted array of all drive-letters in use. > > DriveInfo#getFreeDriveLetters() > Returns sorted array of all drive-letters that are available > for allocation. > > DriveInfo#getDriveType(drive) > Returns string value: > "unknown" - the drive type cannot be determined. > > "no root dir" - the root directory does not exist. > > "Removable" - the drive can be removed from the > drive (removable). > "Fixed" - the disk cannot be removed from the > drive (fixed). > "Remote" - the drive is a remote (network) drive. > > "CDROM" - the drive is a CD-ROM drive. > > "RAM" - the drive is a RAM disk. > > > drive is drive-letter in either ''c'' or ''c:'' or ''c:\\'' form > or UNC path > in either "\\\\server\\share" or > "\\\\server\\share\\" form. > > DriveInfo#isReady(drive) > Returns TRUE if root of the drive is accessible, otherwise > FALSE. This one isn''t really something cool - the function > just tries to chdir to the drive''s root. This takes time and > produces unpleasant sound in case the removable drive is not > loaded. If somebody knows some better way to determine is > there something inside your CD-ROM or FDD - please let me > know (in fact CD-ROMs, RAM drives and network drives return > their status fast, may be some other devices make problem, dunno). > > drive is drive-letter in either ''c'' or ''c:'' or ''c:\\'' form > or UNC path > in either "\\\\server\\share" or > "\\\\server\\share\\" form. > > DriveInfo#getVolumeInfo(drive) > Returns a structure that contains Volume information such as > > VolumeName - name of the specified volume. > VolumeSerialNumber - volume serial number. > MaximumComponentLength - > filename component supported by the specified file system. > A filename component is that portion of a filename > between backslashes. > Indicate that long names are supported by the > specified file system. > For a FAT file system supporting long names, the > function stores > the value 255, rather than the previous 8.3 > indicator. Long names can > also be supported on systems that use the New > Technology file system > (NTFS). > FileSystemName - name of the file system (such as > FAT, FAT32, CDFS or NTFS). > attr - array of constants > FS_CASE_IS_PRESERVED - file system preserves the case of > filenames > FS_CASE_SENSITIVE - file system supports case-sensitive filenames > FS_UNICODE_STORED_ON_DISK - file system supports Unicode > in filenames as they appear on disk > FS_PERSISTENT_ACLS - file system preserves and enforces > ACLs (access-control lists). > For example, NTFS preserves and enforces ACLs, and > FAT does not. > FS_VOL_IS_COMPRESSED - file system supports file-based > compression > FS_FILE_COMPRESSION - specified volume is a compressed > volume; for ex., a DoubleSpace volume > drive is drive-letter in either ''c'' or ''c:'' or ''c:\\'' form. > > DriveInfo#getVersionEx(drive) > Returns a structure that contains Version information such as > MajorVersion - major version number of the operating > system. For Windows NT > version 3.51, it''s 3; for Windows NT > version 4.0, it''s 4; for Windows XP, Windows 2000 and > Windows 2003, it''s 5. > > MinorVersion - minor version number of the operating > system. For Windows NT > version 3.51, it''s 51; for Windows NT > version 4.0, it''s 0. > BuildNumber - build number of the operating system. > PlatformId - 0 for Win32s, 1 for Win95/98, 2 for Win NT > BuildStr - Windows NT: Contains string, such as > "Service Pack 3". > Indicates the latest Service Pack > installed on the system. > If no Service Pack has been installed, the > string is empty. > Windows 95: Contains a null-terminated > string that provides > arbitrary additional information about the > operating system. > > It is pure ruby implementation using Ruby/dl. > > Regards, > > Park Heesob > > _______________________________________________ > win32utils-devel mailing list > win32utils-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-devel > >
Hi Dan,> Hi Heesob, > > I have a couple problems with this. > > First, I guess I didn''t tell you, but I''m opposed to using Ruby/DL for > any of our packages. It''s just not stable, and has 64-bit issues that > are effectively unresolvable. This could be a problem very soon with > 64-bit Windows on the horizon. You can read about Jamis Buck''s negative > experience with Ruby/DL at > http://www.jamisbuck.org/jamis/blog.cgi/programming/ruby/Disappointments > %20in%20Ruby%20Land_20041230165456.tx > > Contrary to whatever Matz has said about Win32API being deprecated, I am > officially declaring Ruby/DL dead for Win32Utils development and > Win32API to be the preferred choice for any pure Ruby development. If > the Win32API package is ever removed from core Ruby, I will fork Ruby. > > This is not an attack on you Heesob. I should have mentioned this on > the list sooner, so it''s my fault. I hedged for a while on the issue > because I wasn''t sure what the future held with regards to Win32API vs. > Ruby/DL. Now that Ruby/DL has proven to be unreliable, I can be more > confident in sticking with Win32API. > > That being said, I won''t force you to rewrite it. Just keep in mind > that all bugs, feature requests, etc, will be directed to *you*. :) >It is test release of driveinfo. There might be many problems with Ruby/DL as you said. At least in my test, it works fine :) I hope the ruby developer make Ruby/DL more reliable in the next version. If you feel unhappy with this package, don''t announce it.> Second, I was hoping to keep the API similar to Mike Hall''s "filesystem" > package. Did you determine that it just wasn''t feasible? I made a > comment about it on the Feature Request. If we can''t make it > compatible, that''s fine, but I thought we should at least try. >I think filesystem is only suitable for *nix, not for windows. If you are sure for compatible package, let me know what''s the correspondent of struct MNTENT or struct statvfs. Regards, Park Heesob
Hi, I committed win32-driveinfo in CVS again. It is now C extension not Ruby/DL.:) Regards, Park Heesob
> -----Original Message----- > From: win32utils-devel-bounces@rubyforge.org > [mailto:win32utils-devel-bounces@rubyforge.org] On Behalf Of > Park Heesob > Sent: Wednesday, February 09, 2005 8:20 AM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] [ANN] win32-driveinfo in CVS > > > Hi, > > I committed win32-driveinfo in CVS again. > It is now C extension not Ruby/DL.:) > > Regards, > > Park HeesobWow, that was fast! Well, since you had originally used a pure Ruby implementation, I *was* going to suggest you reimplement it using OLE + WMI: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/ wmi/computer_system_hardware_classes.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/ wmi/operating_system_classes.asp I was thinking maybe win32_diskdrive from the hardware classes and/or the various filesystem classes (win32_logicaldisk, etc). I''ve only spent about 2 minutes looking at those docs this morning, so maybe that won''t work. Also, since you''ve already reimplemented it once, I dunno how you feel about reimplementing it again. Or, we could provide both, giving the users a choice during installation. Maybe Shanko would like to take a stab at that. :) I was also thinking some more about Mike''s filesystem API. I think we can simulate "Filesystem.stat" easily enough with the information being returned from the "getDriveInfo" method you have now. The struct members wouldn''t be identical, but close enough. The "FileSystem.mounts" method looks like its the same sort of info returned by your getVolumeInfo method. That being said, I don''t want you to think you''re limited to those two methods. We can have more methods, just as long as those two are defined. What do folks think? Dan
Hi Dan,> Wow, that was fast! Well, since you had originally used a pure Ruby > implementation, I *was* going to suggest you reimplement it using OLE + > WMI: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/ > wmi/computer_system_hardware_classes.asp > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/ > wmi/operating_system_classes.asp > > I was thinking maybe win32_diskdrive from the hardware classes and/or > the various filesystem classes (win32_logicaldisk, etc). I''ve only > spent about 2 minutes looking at those docs this morning, so maybe that > won''t work. Also, since you''ve already reimplemented it once, I dunno > how you feel about reimplementing it again. >I have reimplemented some methods with OLE+WMI, But there are no equivalents for some methods like GetDiskFreeSpaceEx in case of UNC Path. If you really wish OLE+WMI implementaion, I will concede it to you :)> Or, we could provide both, giving the users a choice during > installation. Maybe Shanko would like to take a stab at that. :) > > I was also thinking some more about Mike''s filesystem API. I think we > can simulate "Filesystem.stat" easily enough with the information being > returned from the "getDriveInfo" method you have now. The struct > members wouldn''t be identical, but close enough. The > "FileSystem.mounts" method looks like its the same sort of info returned > by your getVolumeInfo method. > > That being said, I don''t want you to think you''re limited to those two > methods. We can have more methods, just as long as those two are > defined. > > What do folks think? > > Dan >Why do you think we should emulate Mike''s filesystem API ? How about giving Mike a chance to emulate windows filesystem? Anyway, my work is just a porting of Perl module and it should stop here. You can modify,reimplement, rename or even drop my work. I have enjoyed myself with Ruby, C, Ruby/DL,OLE and WMI stuffs :) Thanks, Park Heesob
Park Heesob wrote:> Hi Dan, > >>Wow, that was fast! Well, since you had originally used a pure Ruby >>implementation, I *was* going to suggest you reimplement it using OLE + >>WMI: >> >>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/ >>wmi/computer_system_hardware_classes.asp >> >>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/ >>wmi/operating_system_classes.asp >> >>I was thinking maybe win32_diskdrive from the hardware classes and/or >>the various filesystem classes (win32_logicaldisk, etc). I''ve only >>spent about 2 minutes looking at those docs this morning, so maybe that >>won''t work. Also, since you''ve already reimplemented it once, I dunno >>how you feel about reimplementing it again. >> > > I have reimplemented some methods with OLE+WMI, > But there are no equivalents for some methods like GetDiskFreeSpaceEx in case of UNC Path. > If you really wish OLE+WMI implementaion, I will concede it to you :) > > >>Or, we could provide both, giving the users a choice during >>installation. Maybe Shanko would like to take a stab at that. :) >> >>I was also thinking some more about Mike''s filesystem API. I think we >>can simulate "Filesystem.stat" easily enough with the information being >>returned from the "getDriveInfo" method you have now. The struct >>members wouldn''t be identical, but close enough. The >>"FileSystem.mounts" method looks like its the same sort of info returned >>by your getVolumeInfo method. >> >>That being said, I don''t want you to think you''re limited to those two >>methods. We can have more methods, just as long as those two are >>defined. >> >>What do folks think? >> >>Dan >> > > Why do you think we should emulate Mike''s filesystem API ? > How about giving Mike a chance to emulate windows filesystem? > > Anyway, my work is just a porting of Perl module and it should stop here. > You can modify,reimplement, rename or even drop my work.^^^^^^^^^^^^ You guys must have a love-hate relationship. Why drop perfectly good work? Zach
Hi all,> > Why do you think we should emulate Mike''s filesystem API ? > How about > > giving Mike a chance to emulate windows filesystem?There was a thread started by Tim Ferrell (ruby-talk:129645) about disk usage. That led to a discussion about a Windows version and how it would be ideal if we could make the API identical across platforms, so that''s what inspired me. If we can do it, great. If it isn''t practical, then I understand that as well.> > > > Anyway, my work is just a porting of Perl module and it should stop > > here. You can modify,reimplement, rename or even drop my work. > ^^^^^^^^^^^^ > > You guys must have a love-hate relationship. Why drop > perfectly good work? > > ZachHeh - I''m not going to drop his work - it''s far too valuable! I''ll probably just alter it a little. We''ve gone through this before - he hammers out the backend and I hammer out the frontend. :) Also keep in mind that English is not Heesob''s native language, so sometimes things come across a little more harshly than they actually are. Anyway, I''ll take a closer look this weekend. I lost a day yesterday after taking a rather nasty spill while skiing. Ouch. Regards, Dan