Getting Folder Size

When I use File.size(“C:/ruby”), all it returns is 0.
But for files it does work fine. So is there a way to calculate folder
size?

Clement Ow wrote:

When I use File.size(“C:/ruby”), all it returns is 0.
But for files it does work fine. So is there a way to calculate folder
size?

since a directory is just something virtual, it has a size of 0.

you will have to get all of the files the folder includes (recursive)
and sum their sizes up.

Torsten Mangner wrote:

since a directory is just something virtual, it has a size of 0.

you will have to get all of the files the folder includes (recursive)
and sum their sizes up.

or use your operating system to determine the folder size … like

du -s dir

under unix systems.

On Fri, Jul 4, 2008 at 2:06 AM, Clement Ow
[email protected] wrote:

I have options that has nonrecursive requirements… There isnt a direct
method at all that calculates DIR size? Hmmmm, I’m using Windows XP Pro,
so dont suppose the Unix command would work. But, If i use Windows
command, would it probable then?

require ‘win32ole’
=> true

fso = WIN32OLE.new(‘Scripting.FileSystemObject’)
=> #WIN32OLE:0x2c94060

folder = fso.GetFolder(‘C:\ruby\scripts’)
=> #WIN32OLE:0x2c90a48

folder.name
=> “scripts”

folder.size
=> 226746920

folder.path
=> “C:\ruby\scripts”

On 2008-07-04, Clement Ow [email protected] wrote:

I have options that has nonrecursive requirements… There isnt a direct
method at all that calculates DIR size? Hmmmm, I’m using Windows XP Pro,
so dont suppose the Unix command would work. But, If i use Windows
command, would it probable then?

There is no non-recursive solution. There are solutions that put the
recursion in another application, but that’s it.

Torsten Mangner wrote:

Torsten Mangner wrote:

since a directory is just something virtual, it has a size of 0.

you will have to get all of the files the folder includes (recursive)
and sum their sizes up.

or use your operating system to determine the folder size … like

du -s dir

under unix systems.

I have options that has nonrecursive requirements… There isnt a direct
method at all that calculates DIR size? Hmmmm, I’m using Windows XP Pro,
so dont suppose the Unix command would work. But, If i use Windows
command, would it probable then?

Cheers

On Jul 5, 2008, at 1:16 PM, Seebs wrote:

To explain it a little further… technically, even the system is
doing some recursion here when it shows you a folder size.
Directories don’t really have any size to speak of since they are
really just abstract ways to organize data. Doing the recursion is a
good idea. It gives you a chance to get a more accurate result.
Sometimes the system call may be faster though depending on just how
many files are in a directory. The system may have some meta data
available already.

John J. wrote:

To explain it a little further… technically, even the system is
doing some recursion here when it shows you a folder size.

If you right-click on a large Windows folder such as My Documents and
select Properties (in XP at any rate) you can see the system recursing
through and adding up the number of bytes. In theory this figure could
be made available instantly if the system kept track of what was going
on in each folder. But presumably that would slow things down (more).

phlip wrote:

Dave B. wrote:

John J. wrote:

To explain it a little further… technically, even the system is
doing some recursion here when it shows you a folder size.

If you right-click on a large Windows folder such as My Documents and
select Properties (in XP at any rate) you can see the system recursing
through and adding up the number of bytes. In theory this figure could
be made available instantly if the system kept track of what was going
on in each folder. But presumably that would slow things down (more).

Right. In terms of transactions, a file system is a database tuned to
rapidly
read and write individual files. Stashing their intermediate sizes -
into every
directory entry in a system - would slow down every single write to
every file,
and nobody wants that.

Could the original poster attempt what they really need to do, in some
other
way? A spot-check of a limited number of file sizes should be relatively
cheap…

Thanks for all your input, guys, really helped me alot! I actually went
along with the WIN32OLE method, which is totally sweet especially when
you have so many options and lines of code is quite hard to implement a
recursive just calculate the file size(i also dont want to compromise on
the efficiency of the script) =) Thanks once again! Really nice workin
with you guys! =D

Dave B. wrote:

John J. wrote:

To explain it a little further… technically, even the system is
doing some recursion here when it shows you a folder size.

If you right-click on a large Windows folder such as My Documents and
select Properties (in XP at any rate) you can see the system recursing
through and adding up the number of bytes. In theory this figure could
be made available instantly if the system kept track of what was going
on in each folder. But presumably that would slow things down (more).

Right. In terms of transactions, a file system is a database tuned to
rapidly
read and write individual files. Stashing their intermediate sizes -
into every
directory entry in a system - would slow down every single write to
every file,
and nobody wants that.

Could the original poster attempt what they really need to do, in some
other
way? A spot-check of a limited number of file sizes should be relatively
cheap…

From: [email protected]

Thanks for all your input, guys, really helped me alot! I

actually went

along with the WIN32OLE method, which is totally sweet

especially when

you have so many options and lines of code is quite hard to

implement a

recursive just calculate the file size(i also dont want to

compromise on

the efficiency of the script) =) Thanks once again! Really

nice workin

with you guys! =D

interesting. imho, i find pure ruby’s Find.find faster, more expressive,
shorter, and portable, eg,

dirsize =0

Find.find(“c:/ruby187”) do |f| dirsize += File.stat(f).size end
#=> nil

dirsize
#=> 24569727

an added beauty here is that you have granular access to the files. Eg,
what if you want to get the total size of all .rb and .dll files? that
would be pieceofcake then…

kind regards -botp

Peña, Botp wrote:

From: [email protected]

Thanks for all your input, guys, really helped me alot! I

actually went

along with the WIN32OLE method, which is totally sweet

especially when

you have so many options and lines of code is quite hard to

implement a

recursive just calculate the file size(i also dont want to

compromise on

the efficiency of the script) =) Thanks once again! Really

nice workin

with you guys! =D

interesting. imho, i find pure ruby’s Find.find faster, more expressive,
shorter, and portable, eg,

dirsize =0

Find.find(“c:/ruby187”) do |f| dirsize += File.stat(f).size end
#=> nil

dirsize
#=> 24569727

Hmm yea, this is quite an interesting way too, and more handy if you
need to have more options like finding the size or dir count of the
files in a certain directory. It is also easier to modify the code and
get what you want eh? Thanks for the input botp! =) It has been a great
learning experience so far!

But just curious actually, that if there is any documentation that
pertains to the win32ole methods, not the one from the ruby
documentation of WIN32OLE but more of the methods that come along with
it, not really sure how to explain but examples like these:

folder = fso.GetFolder(‘C:\ruby\scripts’)
=> #WIN32OLE:0x2c90a48

folder.name
=> “scripts”

folder.size
=> 226746920

folder.path
=> “C:\ruby\scripts”

so far I only know of GetFolder,GetFile, name, size, path kinda methods.
just wondering if anyone knows if there is a list of such methods which
might be really helpful in manipulating files and folders?

Also, for fso = WIN32OLE.new(‘Scripting.FileSystemObject’)is
FileSystemObject part of ruby? The documentation in ruby states that:
“The first argument should be CLSID or PROGID. If second argument host
specified, then returns OLE Automation object on host.” Does anyone know
what this means?

Thanks!

From: [email protected]

But just curious actually, that if there is any documentation that

pertains to the win32ole methods, not the one from the ruby

clement, win32ole is mainly microsoft-ism. Ruby’s win32ole is just a
beautiful ruby wrapper for windows ole. You’ll have to dig the microsoft
dsn site or download some free ole browsers to get a full
listing/documentation of the ole methods in windows… You can create
your own ole dll but then again, you still have to read microsoft specs
on that too…

kind regards -botp

On Jul 4, 12:19 am, Clement Ow [email protected] wrote:

When I use File.size(“C:/ruby”), all it returns is 0.
But for files it does work fine. So is there a way to calculate folder
size?

Danger: http://blogs.msdn.com/oldnewthing/archive/2004/12/28/336219.aspx

Regards,

Dan

Peña, Botp wrote:

From: [email protected]

But just curious actually, that if there is any documentation that

pertains to the win32ole methods, not the one from the ruby

clement, win32ole is mainly microsoft-ism. Ruby’s win32ole is just a
beautiful ruby wrapper for windows ole. You’ll have to dig the microsoft
dsn site or download some free ole browsers to get a full
listing/documentation of the ole methods in windows… You can create
your own ole dll but then again, you still have to read microsoft specs
on that too…

kind regards -botp

Ah icic. Very interesting indeed… :)So to know what to put in the
string after new, WIN32OLE.new(‘Scripting.FileSystemObject’)I have to go
to the microsoft dsn site to see what is in the syntax? Would it be a
universal type of syntax here that can be used with any other types of
programming languages that support WIN32OLE?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs