Discussion:
Function in os module for available disk space, why not?
(too old to reply)
Dinu Gherman
2001-03-19 11:57:49 UTC
Permalink
is there a simple way (or any way at all) to find out for
any given hard disk how much free space is left on that
device? I looked into the os module, but either not hard
enough or there is no such function. Of course, the ideal
solution would be platform-independant, too... :)
Is there any good reason for not having a cross-platform
solution to this? I'm certainly not the first to ask for
such a function and it certainly exists for all platforms,
doesn't it?

Unfortunately, OS problems like that make it rather impossi-
ble to write truly cross-platform applications in Python,
even if it is touted to be exactly that.

I know that OS differ in the services they provide, but in
this case it seems to me that each one *must* have such a
function, so I don't understand why it's not there...

Regards,

Dinu
--
Dinu C. Gherman
ReportLab Consultant - http://www.reportlab.com
................................................................
"The only possible values [for quality] are 'excellent' and 'in-
sanely excellent', depending on whether lives are at stake or
not. Otherwise you don't enjoy your work, you don't work well,
and the project goes down the drain."
(Kent Beck, "Extreme Programming Explained")
Thomas Wouters
2001-03-19 12:07:13 UTC
Permalink
Post by Dinu Gherman
is there a simple way (or any way at all) to find out for
any given hard disk how much free space is left on that
device? I looked into the os module, but either not hard
enough or there is no such function. Of course, the ideal
solution would be platform-independant, too... :)
Is there any good reason for not having a cross-platform
solution to this? I'm certainly not the first to ask for
such a function and it certainly exists for all platforms,
doesn't it?
I think the main reason such a function does not exist is that no-one wrote
it. If you can write a portable function, or fake one by making different
implementations on different platforms, please contribute ;) Step one is
making an inventory of the available functions, though, so you know how
large an intersection you have to work with. The fact that you have to start
that study is probably the #1 reason no-one's done it yet :)
--
Thomas Wouters <***@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Dinu Gherman
2001-03-19 12:21:44 UTC
Permalink
Post by Thomas Wouters
it. If you can write a portable function, or fake one by making different
implementations on different platforms, please contribute ;) Step one is
making an inventory of the available functions, though, so you know how
large an intersection you have to work with. The fact that you have to start
that study is probably the #1 reason no-one's done it yet :)
Well, this is the usual "If you need it, do it yourself!"
answer, that bites the one who dares to speak up for all
those hundreds who don't... isn't it?

Rather than asking one non-expert in N-1 +/- 1 operating
systems to implement it, why not ask N experts in imple-
menting Python on 1 platform to do the job? (Notice the
potential for parallelism?! :)

Uhmm, seriously, does it really take 10 years for such an
issue to creep up high enough on the priority ladder of
Python-Labs?

In any case it doesn't sound like a Python 3000 feature to
me, or maybe it should?

Regards,

Dinu
--
Dinu C. Gherman
ReportLab Consultant - http://www.reportlab.com
................................................................
"The only possible values [for quality] are 'excellent' and 'in-
sanely excellent', depending on whether lives are at stake or
not. Otherwise you don't enjoy your work, you don't work well,
and the project goes down the drain."
(Kent Beck, "Extreme Programming Explained")
M.-A. Lemburg
2001-03-19 12:34:45 UTC
Permalink
Post by Dinu Gherman
Post by Thomas Wouters
it. If you can write a portable function, or fake one by making different
implementations on different platforms, please contribute ;) Step one is
making an inventory of the available functions, though, so you know how
large an intersection you have to work with. The fact that you have to start
that study is probably the #1 reason no-one's done it yet :)
Well, this is the usual "If you need it, do it yourself!"
answer, that bites the one who dares to speak up for all
those hundreds who don't... isn't it?
Rather than asking one non-expert in N-1 +/- 1 operating
systems to implement it, why not ask N experts in imple-
menting Python on 1 platform to do the job? (Notice the
potential for parallelism?! :)
I think the problem with this one really is the differences
in OS designs, e.g. on Windows you have the concept of drive
letters where on Unix you have mounted file systems. Then there
also is the concept of disk space quota per user which would
have to be considered too.

Also, calculating the available disk space may return false
results (e.g. for Samba shares).

Perhaps what we really need is some kind of probing function
which tests whether a certain amount of disk space would be
available ?!
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Pages: http://www.lemburg.com/python/
M.-A. Lemburg
2001-03-19 13:07:25 UTC
Permalink
Post by M.-A. Lemburg
I think the problem with this one really is the differences
in OS designs, e.g. on Windows you have the concept of drive
letters where on Unix you have mounted file systems. Then there
also is the concept of disk space quota per user which would
have to be considered too.
import os
free = os.getfreespace('c:\\') # on Win
free = os.getfreespace('/hd5') # on Unix-like boxes
free = os.getfreespace('Mactintosh HD') # on Macs
free = os.getfreespace('ZIP-1') # on Macs, Win, ...
etc. where the string passed is, a-priori, a name known
by the OS for some permanent or removable drive. Network
drives might be slightly more tricky, but probably not
entirely impossible, I guess.
This sounds like a lot of different platform C APIs would need
to be wrapped first, e.g. quotactrl, getrlimit (already done)
+ a bunch of others since "get free space" is usually a file system
dependent call.

I guess we should take a look at how "df" does this on Unix
and maybe trick Mark Hammond into looking up the win32 API ;-)
Post by M.-A. Lemburg
Perhaps what we really need is some kind of probing function
which tests whether a certain amount of disk space would be
available ?!
Something like incrementally stuffing it with junk data until
you get an exception, right? :)
Yep. Actually opening a file in record mode and then using
file.seek() should work on many platforms.
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Pages: http://www.lemburg.com/python/
Greg Ewing
2001-03-20 00:19:35 UTC
Permalink
Post by M.-A. Lemburg
Actually opening a file in record mode and then using
file.seek() should work on many platforms.
Not on Unix! No space is actually allocated until you
write something, regardless of where you seek to. And
then only the blocks that you touch (files can have
holes in them).

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
***@cosc.canterbury.ac.nz +--------------------------------------+
Thomas Wouters
2001-03-19 12:43:23 UTC
Permalink
Post by Dinu Gherman
Post by Thomas Wouters
it. If you can write a portable function, or fake one by making different
implementations on different platforms, please contribute ;) Step one is
making an inventory of the available functions, though, so you know how
large an intersection you have to work with. The fact that you have to start
that study is probably the #1 reason no-one's done it yet :)
Well, this is the usual "If you need it, do it yourself!"
answer, that bites the one who dares to speak up for all
those hundreds who don't... isn't it?
Rather than asking one non-expert in N-1 +/- 1 operating
systems to implement it, why not ask N experts in imple-
menting Python on 1 platform to do the job? (Notice the
potential for parallelism?! :)
Uhmm, seriously, does it really take 10 years for such an
issue to creep up high enough on the priority ladder of
Python-Labs?
In any case it doesn't sound like a Python 3000 feature to
me, or maybe it should?
Nope. But you seem to misunderstand the idea behind Python development (and
most of open-source development.) PythonLabs has a *lot* of stuff they have
to do, and you cannot expect them to do everything. Truth is, this is not
likely to be done by Pythonlabs, and it will never be done unless someone
does it. It might sound harsh and unfriendly, but it's just a fact. It
doesn't mean *you* have to do it, but that *someone* has to do it. Feel free
to find someone to do it :)

As for the parallelism: that means getting even more people to volunteer for
the task. And the person(s) doing it still have to figure out the common
denominators in 'get me free disk space info'.

And the fact that it's *been* 10 years shows that noone cares enough about
the free disk space issue to actually get people to code it. 10 years filled
with a fair share of C programmers starting to use Python, so plenty of
those people could've done it :)
--
Thomas Wouters <***@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Dinu Gherman
2001-03-19 12:58:48 UTC
Permalink
Post by Thomas Wouters
Nope. But you seem to misunderstand the idea behind Python development (and
most of open-source development.)
Not sure what makes you think that, but anyway.
Post by Thomas Wouters
PythonLabs has a *lot* of stuff they have
to do, and you cannot expect them to do everything. Truth is, this is not
likely to be done by Pythonlabs, and it will never be done unless someone
does it.
Apparently, I agree, I know less about what makes truth here.
What is probably valid is that having much to do is true for
everybody and not much of an argument, is it?
Post by Thomas Wouters
As for the parallelism: that means getting even more people to volunteer for
the task. And the person(s) doing it still have to figure out the common
denominators in 'get me free disk space info'.
I'm afraid this is like argueing in circles.
Post by Thomas Wouters
And the fact that it's *been* 10 years shows that noone cares enough about
the free disk space issue to actually get people to code it. 10 years filled
with a fair share of C programmers starting to use Python, so plenty of
those people could've done it :)
I'm afraid, again, but the impression you have of nobody in ten
years asking for this function is just that, an impression,
unless *somebody* prooves the contrary.

All I can say is that I'm writing an app that I want to be
cross-platform and that Python does not allow it to be just
that, while Google gives you 17400 hits if you look for
"python cross-platform". Now, this is also some kind of
*truth* if only one of a mismatch between reality and wish-
ful thinking...

Regards,

Dinu
Thomas Wouters
2001-03-19 13:18:34 UTC
Permalink
Post by Dinu Gherman
All I can say is that I'm writing an app that I want to be
cross-platform and that Python does not allow it to be just
that, while Google gives you 17400 hits if you look for
"python cross-platform". Now, this is also some kind of
*truth* if only one of a mismatch between reality and wish-
ful thinking...
I'm sure I agree, but I don't see the value in dropping everything to write
a function so Python can be that much more cross-platform. (That's just me,
though.) Python wouldn't *be* as cross-platform as it is now if not for a
group of people who weren't satisfied with it, and improved on it. And a lot
of those people were not Guido or even of the current PythonLabs team.

I've never really believed in the 'true cross-platform nature' of Python,
mostly because I know it can't *really* be true. Most of my scripts are not
portably to non-UNIX platforms, due to the use of sockets, pipes, and
hardcoded filepaths (/usr/...). Even if I did, I can hardly agree that
because there is no portable way (if any at all) to find out howmany
diskspace is free, it isn't cross-platform. Just *because* it lacks that
function makes it more cross-platform: platforms might not have the concept
of 'free space' :)
--
Thomas Wouters <***@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Dinu Gherman
2001-03-19 13:23:51 UTC
Permalink
Post by Thomas Wouters
I've never really believed in the 'true cross-platform nature' of Python,
mostly because I know it can't *really* be true. Most of my scripts are not
portably to non-UNIX platforms, due to the use of sockets, pipes, and
hardcoded filepaths (/usr/...). Even if I did, I can hardly agree that
because there is no portable way (if any at all) to find out howmany
diskspace is free, it isn't cross-platform. Just *because* it lacks that
function makes it more cross-platform: platforms might not have the concept
of 'free space' :)
Hmm, that means we better strip the standard library off
most of its modules (why not all?), because the less
content there is, the more cross-platform it will be,
right?

Well, if the concept is not there, simply throw a neat
ConceptException! ;-)

Dinu
Tim Peters
2001-03-20 01:48:27 UTC
Permalink
Here's a radical suggestion: Start a x-platform project on SourceForge,
devoted to producing a C library with a common interface for
platform-dependent crud like "how big is this file?" and "how many bytes free
on this disk?" and "how can I execute a shell command in a portable way?"
(e.g., Tcl's "exec" emulates a subset of Bourne shell syntax, including
redirection and pipes, even on Windows 3.1).

OK, that's too useful. Nevermind ...
Fredrik Lundh
2001-03-20 07:36:59 UTC
Permalink
Post by Tim Peters
Here's a radical suggestion: Start a x-platform project on SourceForge,
devoted to producing a C library with a common interface for
platform-dependent crud like "how big is this file?" and "how many bytes free
on this disk?" and "how can I execute a shell command in a portable way?"
(e.g., Tcl's "exec" emulates a subset of Bourne shell syntax, including
redirection and pipes, even on Windows 3.1).
counter-suggestion:

add partial os.statvfs emulation to the posix module for Windows
(and Mac), and write helpers for shutil to do the fancy stuff you
mentioned before.

Cheers /F
Tim Peters
2001-03-20 08:30:18 UTC
Permalink
[Fredrik Lundh]
Post by Fredrik Lundh
add partial os.statvfs emulation to the posix module for Windows
(and Mac), and write helpers for shutil to do the fancy stuff you
mentioned before.
One of the best things Python ever did was to introduce os.path.getsize() +
friends, saving the bulk of the world from needing to wrestle with the
obscure Unix stat() API. os.chmod() is another x-platform teachability pain;
if there's anything worth knowing in the bowels of statvfs(), let's please
spell it in a human-friendly way from the start.
Fredrik Lundh
2001-03-20 08:58:53 UTC
Permalink
Post by Tim Peters
One of the best things Python ever did was to introduce os.path.getsize() +
friends, saving the bulk of the world from needing to wrestle with the
obscure Unix stat() API.
yup (I remember lobbying for those years ago), but that doesn't
mean that we cannot make already existing low-level APIs work
on as many platforms as possible...

(just like os.popen etc)

adding os.statvfs for windows is pretty much a bug fix (for 2.1?),
but adding a new API is not (2.2).
Post by Tim Peters
os.chmod() is another x-platform teachability pain
shutil.chmod("file", "g+x"), anyone?
Post by Tim Peters
if there's anything worth knowing in the bowels of statvfs(), let's
please spell it in a human-friendly way from the start.
how about os.path.getfreespace("path") and
os.path.gettotalspace("path") ?

Cheers /F
M.-A. Lemburg
2001-03-20 21:03:40 UTC
Permalink
Post by Fredrik Lundh
Post by Tim Peters
One of the best things Python ever did was to introduce os.path.getsize() +
friends, saving the bulk of the world from needing to wrestle with the
obscure Unix stat() API.
yup (I remember lobbying for those years ago), but that doesn't
mean that we cannot make already existing low-level APIs work
on as many platforms as possible...
(just like os.popen etc)
adding os.statvfs for windows is pretty much a bug fix (for 2.1?),
but adding a new API is not (2.2).
Post by Tim Peters
os.chmod() is another x-platform teachability pain
shutil.chmod("file", "g+x"), anyone?
Wasn't shutil declared obsolete ?
Post by Fredrik Lundh
Post by Tim Peters
if there's anything worth knowing in the bowels of statvfs(), let's
please spell it in a human-friendly way from the start.
how about os.path.getfreespace("path") and
os.path.gettotalspace("path") ?
Anybody care to add the missing parts in:

import sys,os

try:
os.statvfs

except AttributeError:
# Win32 implementation...
# Mac implementation...
pass

else:
import statvfs

def freespace(path):
""" freespace(path) -> integer
Return the number of bytes available to the user on the file system
pointed to by path."""
s = os.statvfs(path)
return s[statvfs.F_BAVAIL] * long(s[statvfs.F_BSIZE])

if __name__=='__main__':
path = sys.argv[1]
print 'Free space on %s: %i kB (%i bytes)' % (path,
freespace(path) / 1024,
freespace(path))


totalspace() should be just as easy to add and I'm pretty
sure that you can get that information on *all* platforms
(not necessarily using the same APIs though).
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Pages: http://www.lemburg.com/python/
Aahz Maruch
2001-03-20 21:38:27 UTC
Permalink
Post by M.-A. Lemburg
Wasn't shutil declared obsolete ?
<blink> What?!
--
--- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6 http://www.rahul.net/aahz
Androgynous poly kinky vanilla queer het

I don't really mind a person having the last whine, but I do mind
someone else having the last self-righteous whine.
M.-A. Lemburg
2001-03-21 10:02:54 UTC
Permalink
Post by Aahz Maruch
Post by M.-A. Lemburg
Wasn't shutil declared obsolete ?
<blink> What?!
Guido once pronounced on this... mostly because of the comment
at the top regarding cross-platform compatibility:

"""Utility functions for copying files and directory trees.

XXX The functions here don't copy the resource fork or other metadata on Mac.

"""
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Pages: http://www.lemburg.com/python/
Greg Ewing
2001-03-22 01:37:00 UTC
Permalink
Post by M.-A. Lemburg
XXX The functions here don't copy the resource fork or other metadata on Mac.
Wouldn't it be better to fix these functions on the Mac
instead of depriving everyone else of them?

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
***@cosc.canterbury.ac.nz +--------------------------------------+
Neil Hodgson
2001-03-22 02:07:28 UTC
Permalink
This post might be inappropriate. Click to display it.
Greg Ward
2001-03-22 16:50:43 UTC
Permalink
Post by Neil Hodgson
Then they should be fixed for Windows as well where they don't copy
secondary forks either. While not used much by native code, forks are
commonly used on NT servers which serve files to Macintoshes.
There is also the issue of other metadata. Should shutil optionally copy
ownership information? Access Control Lists? Summary information? A really
well designed module here could be very useful but quite some work.
There's a pretty good 'copy_file()' routine in the Distutils; I found
shutil quite inadequate, so rolled my own. Jack Jansen patched it so it
does the "right thing" on Mac OS. By now, it has probably copied many
files all over the place on all of your computers, so it sounds like it
works. ;-)

See the distutils.file_util module for implementation and documentation.

Greg
--
Greg Ward - Unix bigot ***@python.net
http://starship.python.net/~gward/
Sure, I'm paranoid... but am I paranoid ENOUGH?
Barry A. Warsaw
2001-03-22 03:16:30 UTC
Permalink
GE> Wouldn't it be better to fix these functions on the Mac
GE> instead of depriving everyone else of them?

Either way, shutil sure is useful!
Guido van Rossum
2001-03-22 13:51:16 UTC
Permalink
Post by Barry A. Warsaw
GE> Wouldn't it be better to fix these functions on the Mac
GE> instead of depriving everyone else of them?
Either way, shutil sure is useful!
Yes, but deceptively so. What should we do? Anyway, it doesn't
appear to be officially deprecated yet (can't see it in the docs) and
I think it may be best to keep it that way.

--Guido van Rossum (home page: http://www.python.org/~guido/)
Peter Funk
2001-03-22 14:17:46 UTC
Permalink
Hi,
Post by Guido van Rossum
Post by Barry A. Warsaw
GE> Wouldn't it be better to fix these functions on the Mac
GE> instead of depriving everyone else of them?
Either way, shutil sure is useful!
Yes, but deceptively so. What should we do? Anyway, it doesn't
appear to be officially deprecated yet (can't see it in the docs) and
I think it may be best to keep it that way.
A very simple idea would be, to provide two callback hooks,
which will be invoked by each call to copyfile or remove.

Example: Someone uses the package netatalk on Linux to provide file
services to Macs. netatalk stores the resource forks in hidden sub
directories called .AppleDouble. The callback function could than
copy the .AppleDouble/files around using shutil.copyfile itself.

Regards, Peter
Greg Ewing
2001-03-22 22:36:02 UTC
Permalink
Post by Peter Funk
netatalk stores the resource forks in hidden sub
directories called .AppleDouble.
None of that is relevant if the copying is being done from
the Mac end. To the Mac it just looks like a normal Mac
file, so the standard Mac file-copying techniques will work.
No need for any callbacks.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
***@cosc.canterbury.ac.nz +--------------------------------------+
Peter Funk
2001-03-22 23:10:46 UTC
Permalink
Hi,
Post by Greg Ewing
Post by Peter Funk
netatalk stores the resource forks in hidden sub
directories called .AppleDouble.
None of that is relevant if the copying is being done from
the Mac end. To the Mac it just looks like a normal Mac
file, so the standard Mac file-copying techniques will work.
No need for any callbacks.
You are right and I know this. But if you program an application,
which should work on the Unix/Linux side (for example a filemanager
or something similar), you have to pay attention to this files on
your own. The same holds true for thumbnail images usually stored
in a .xvpics subdirectory.

All current filemanagers on Linux (KDE kfm, Gnome gmc) are flawed
in this respect.

Regards, Peter
P.S.: I'm not going to write a GUI file manager in Python and using
shutil right now. So this discussion is somewhat academic.
--
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
Greg Ewing
2001-03-25 21:53:02 UTC
Permalink
Post by Peter Funk
All current filemanagers on Linux (KDE kfm, Gnome gmc) are flawed
in this respect.
I don't think you can call that a "flaw", given that these
filemanagers are only designed to deal with Unix file systems.

I think it's reasonable to only expect things in the platform
os module to deal with the platform's native file system.
Trying to anticipate how every platform's cross-platform
file servers for all other platforms are going to store their
data just isn't practical.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
***@cosc.canterbury.ac.nz +--------------------------------------+
Guido van Rossum
2001-03-26 02:03:52 UTC
Permalink
Post by Greg Ewing
Post by Peter Funk
All current filemanagers on Linux (KDE kfm, Gnome gmc) are flawed
in this respect.
I don't think you can call that a "flaw", given that these
filemanagers are only designed to deal with Unix file systems.
I think it's reasonable to only expect things in the platform
os module to deal with the platform's native file system.
Trying to anticipate how every platform's cross-platform
file servers for all other platforms are going to store their
data just isn't practical.
You say that now, but as such cross-system servers become more common,
we should expect the tools to deal with them well, rather than
complain "the other guy doesn't play by our rules".

--Guido van Rossum (home page: http://www.python.org/~guido/)
Michael Hudson
2001-03-26 13:18:26 UTC
Permalink
Post by Guido van Rossum
Post by Greg Ewing
Post by Peter Funk
All current filemanagers on Linux (KDE kfm, Gnome gmc) are flawed
in this respect.
I don't think you can call that a "flaw", given that these
filemanagers are only designed to deal with Unix file systems.
I think it's reasonable to only expect things in the platform
os module to deal with the platform's native file system.
Trying to anticipate how every platform's cross-platform
file servers for all other platforms are going to store their
data just isn't practical.
You say that now, but as such cross-system servers become more common,
we should expect the tools to deal with them well, rather than
complain "the other guy doesn't play by our rules".
So, a goal for 2.2: getting moving/copying/deleting of files and
directories working properly (ie. using native APIs) on all major
supported platforms, with all the legwork that implies. We're not
really very far from this now, are we? Perhaps (the functionality of)
shutil.{rmtree,copy,copytree} should move into os and if necessary be
implemented in nt or dos or mac or whatever. Any others?

Cheers,
M.
--
39. Re graphics: A picture is worth 10K words - but only those
to describe the picture. Hardly any sets of 10K words can be
adequately described with pictures.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Guido van Rossum
2001-03-26 15:32:09 UTC
Permalink
Post by Michael Hudson
So, a goal for 2.2: getting moving/copying/deleting of files and
directories working properly (ie. using native APIs) on all major
supported platforms, with all the legwork that implies. We're not
really very far from this now, are we? Perhaps (the functionality of)
shutil.{rmtree,copy,copytree} should move into os and if necessary be
implemented in nt or dos or mac or whatever. Any others?
Given that it's currently in shutil, please just consider improving
that, unless you believe that the basic API should be completely
different. This sounds like something PEP-worthy!

--Guido van Rossum (home page: http://www.python.org/~guido/)
Greg Ward
2001-03-27 17:13:35 UTC
Permalink
This post might be inappropriate. Click to display it.
Fred L. Drake, Jr.
2001-03-22 14:57:47 UTC
Permalink
Post by Guido van Rossum
Yes, but deceptively so. What should we do? Anyway, it doesn't
appear to be officially deprecated yet (can't see it in the docs) and
I think it may be best to keep it that way.
I don't think it's deceived me yet! I see no reason to deprecate
it, and I don't recall anyone telling me it should be. Nor do I
recall a discussion here suggesting that it should be.
If it has hidden corners that I just haven't run into (and it *has*
been pointed out that it does have corners, at least on some
platforms), why don't we just consider those bugs that can be fixed?


-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Digital Creations
Fredrik Lundh
2001-03-19 13:04:59 UTC
Permalink
Post by Dinu Gherman
Well, this is the usual "If you need it, do it yourself!"
answer, that bites the one who dares to speak up for all
those hundreds who don't... isn't it?
os.statvfs("/")
(8192, 512, 524288, 365788, 348336, 600556, 598516, 598516, 0, 255)

here, the root disk holds 524288x512 bytes, with 348336x512
bytes free for the current user, and 365788x512 bytes available
for root.

(the statvfs module contains indices for accessing this "struct")

Implementing a small subset of statvfs for Windows wouldn't
be that hard (possibly returning None for fields that don't make
sense, or are too hard to figure out).

(and with win32all, I'm sure it can be done without any C code).

Cheers /F
Dinu Gherman
2001-03-19 13:32:17 UTC
Permalink
Post by Fredrik Lundh
os.statvfs("/")
(8192, 512, 524288, 365788, 348336, 600556, 598516, 598516, 0, 255)
here, the root disk holds 524288x512 bytes, with 348336x512
bytes free for the current user, and 365788x512 bytes available
for root.
(the statvfs module contains indices for accessing this "struct")
Implementing a small subset of statvfs for Windows wouldn't
be that hard (possibly returning None for fields that don't make
sense, or are too hard to figure out).
(and with win32all, I'm sure it can be done without any C code).
Cheers /F
Everything correct!

I'm just trying to make the point that from a user perspective
it would be more complete to have such a function in the os
module (where it belongs), that would also work on Macs e.g.,
as well as more conveniant, because even when that existed in
modules like win32api (where it does) and in one of the (many)
mac* ones (which I don't know yet if it does) it would save
you the if-statement on sys.platform.

It sounds silly to me if people now pushed into learning Py-
thon as a first programming language had to use such state-
ments to get along, but were given the 'gift' of 1/2 = 0.5
which we seem to spend an increasing amount of brain cycles
on...

Regards,

Dinu
--
Dinu C. Gherman
ReportLab Consultant - http://www.reportlab.com
................................................................
"The only possible values [for quality] are 'excellent' and 'in-
sanely excellent', depending on whether lives are at stake or
not. Otherwise you don't enjoy your work, you don't work well,
and the project goes down the drain."
(Kent Beck, "Extreme Programming Explained")
Gordon McMillan
2001-03-19 14:27:04 UTC
Permalink
Dinu Gherman wrote:

[disk free space...]
I'm just trying to make the point that from a user perspective it
would be more complete to have such a function in the os module
(where it belongs), that would also work on Macs e.g., as well as
more conveniant, because even when that existed in modules like
win32api (where it does) and in one of the (many) mac* ones
(which I don't know yet if it does) it would save you the
if-statement on sys.platform.
Considering that:
- it's not uncommon to map things into the filesystem's
namespace for which "free space" is meaningless
- for network mapped storage space it's quite likely you can't
get a meaningful number
- for compressed file systems the number will be inaccurate
- even if you get an accurate answer, the space may not be
there when you go to use it (so need try... except anyway)

I find it perfectly sensible that Python does not dignify this
mess with an official function.

- Gordon
Dinu Gherman
2001-03-19 15:32:51 UTC
Permalink
Post by Gordon McMillan
- it's not uncommon to map things into the filesystem's
namespace for which "free space" is meaningless
Unless I'm totally stupid, I see the concept of "free space" as
being tied to the *device*, not to anything being mapped to it
or not.
Post by Gordon McMillan
- for network mapped storage space it's quite likely you can't
get a meaningful number
Fine, then let's play the exception blues...
Post by Gordon McMillan
- for compressed file systems the number will be inaccurate
Then why is the OS function call there...? And: nobody can *seri-
ously* expect an accurate figure of the remaining space for com-
pressed file systems, anyway, and I think nobody does! But there
will always be some number >= 0 of uncompressed available bytes
left.
Post by Gordon McMillan
- even if you get an accurate answer, the space may not be
there when you go to use it (so need try... except anyway)
The same holds for open(path, 'w') - and still this function is
considered useful, isn't it?!
Post by Gordon McMillan
I find it perfectly sensible that Python does not dignify this
mess with an official function.
Well, I have yet to see a good argument against this...

Regards,

Dinu
Guido van Rossum
2001-03-19 14:58:29 UTC
Permalink
Post by Dinu Gherman
I'm just trying to make the point that from a user perspective
it would be more complete to have such a function in the os
module (where it belongs), that would also work on Macs e.g.,
as well as more conveniant, because even when that existed in
modules like win32api (where it does) and in one of the (many)
mac* ones (which I don't know yet if it does) it would save
you the if-statement on sys.platform.
Yeah, yeah, yeah. Whine, whine, whine. As has been made abundantly
clear, doing this cross-platform requires a lot of detailed platform
knowledge. We at PythonLabs don't have all the wisdom, and we often
rely on outsiders to help us out. Until now, finding out how much
free space there is on a disk hasn't been requested much (in fact I
don't recall seeing a request for it before). That's why it isn't
already there -- that plus the fact that traditionally on Unix this
isn't easy to find out (statvfs didn't exist when I wrote most of the
posix module). I'm not against adding it, but I'm not particularly
motivated to add it myself because I have too much to do already (and
the same's true for all of us here at PythonLabs).
Post by Dinu Gherman
It sounds silly to me if people now pushed into learning Py-
thon as a first programming language had to use such state-
ments to get along, but were given the 'gift' of 1/2 = 0.5
which we seem to spend an increasing amount of brain cycles
on...
I would hope that you agree with me though that the behavior of
numbers is a lot more fundamental to education than finding out
available disk space. The latter is just a system call of use to a
small number of professionals. The former has usability implications
for all Python users.

--Guido van Rossum (home page: http://www.python.org/~guido/)
Dinu Gherman
2001-03-19 16:06:27 UTC
Permalink
Yeah, yeah, yeah. Whine, whine, whine. [...]
I'm not against adding it, but I'm not particularly motivated
to add it myself [...]
Good! After doing a quick research on Google it turns out
this function is also available on MacOS, as expected, named
PBHGetVInfo(). See this page for details plus a sample Pascal
function using it:

http://developer.apple.com/techpubs/mac/Files/Files-96.html

I'm not sure what else is needed to use it, but at least it's
there and maybe somebody more of a Mac expert than I am could
help out here... I'm going to continue this on c.l.p. in the
original thread... Hey, maybe it is already available in one
of the many mac packages. Well, I'll start some digging...
I would hope that you agree with me though that the behavior of
numbers is a lot more fundamental to education than finding out
available disk space. The latter is just a system call of use
to a small number of professionals. The former has usability
implications for all Python users.
I do agree, sort of, but it appears that often there is much
more work being spent on fantastic new features, where im-
proving existing ones would also be very beneficial. For me
at least, there is considerable value in a system's consisten-
cy and completeness and not only in its number of features.

Thanks everybody (now that Guido has spoken we have to finish)!
It was fun! :)

Regards,

Dinu
--
Dinu C. Gherman
ReportLab Consultant - http://www.reportlab.com
................................................................
"The only possible values [for quality] are 'excellent' and 'in-
sanely excellent', depending on whether lives are at stake or
not. Otherwise you don't enjoy your work, you don't work well,
and the project goes down the drain."
(Kent Beck, "Extreme Programming Explained")
M.-A. Lemburg
2001-03-19 16:07:10 UTC
Permalink
Post by Fredrik Lundh
Post by Dinu Gherman
Well, this is the usual "If you need it, do it yourself!"
answer, that bites the one who dares to speak up for all
those hundreds who don't... isn't it?
os.statvfs("/")
(8192, 512, 524288, 365788, 348336, 600556, 598516, 598516, 0, 255)
here, the root disk holds 524288x512 bytes, with 348336x512
bytes free for the current user, and 365788x512 bytes available
for root.
(the statvfs module contains indices for accessing this "struct")
Implementing a small subset of statvfs for Windows wouldn't
be that hard (possibly returning None for fields that don't make
sense, or are too hard to figure out).
(and with win32all, I'm sure it can be done without any C code).
It seems that all we need is Jack to port this to the Mac
and we have a working API here :-)

Let's do it...

import sys,os

try:
os.statvfs

except KeyError:
# Win32 implementation...
# Mac implementation...
pass

else:
import statvfs

def freespace(path):
""" freespace(path) -> integer
Return the number of bytes available to the user on the file system
pointed to by path."""
s = os.statvfs(path)
return s[statvfs.F_BAVAIL] * long(s[statvfs.F_BSIZE])

if __name__=='__main__':
path = sys.argv[1]
print 'Free space on %s: %i kB (%i bytes)' % (path,
freespace(path) / 1024,
freespace(path))
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Pages: http://www.lemburg.com/python/
Fredrik Lundh
2001-03-20 19:20:38 UTC
Permalink
Post by M.-A. Lemburg
return s[statvfs.F_BAVAIL] * long(s[statvfs.F_BSIZE])
F_FRAVAIL, not F_BAVAIL

(and my plan is to make a statvfs subset available on
all platforms, which makes your code even simpler...)

Cheers /F
Fredrik Lundh
2001-03-22 17:09:49 UTC
Permalink
Post by Fredrik Lundh
(and my plan is to make a statvfs subset available on
all platforms, which makes your code even simpler...)
windows patch here:
http://sourceforge.net/tracker/index.php?func=detail&aid=410547&group_id=5470&atid=305470

guess it has to wait for 2.2, though...

Cheers /F
Moshe Zadka
2001-03-19 16:00:01 UTC
Permalink
Post by Dinu Gherman
is there a simple way (or any way at all) to find out for
any given hard disk how much free space is left on that
device? I looked into the os module, but either not hard
enough or there is no such function. Of course, the ideal
solution would be platform-independant, too... :)
Is there any good reason for not having a cross-platform
solution to this? I'm certainly not the first to ask for
such a function and it certainly exists for all platforms,
doesn't it?
No, it doesn't.
Specifically, the information is always unreliable, especially
when you start considering NFS mounted directories and things
like that.
Post by Dinu Gherman
I know that OS differ in the services they provide, but in
this case it seems to me that each one *must* have such a
function
This doesn't have a *meaning* in UNIX. (In the sense that I can
think of so many special cases, that having a half-working implementation
is worse then nothing)
--
"I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
-- Wichert Akkerman (on debian-private)| easier, more seductive.
For public key, finger ***@debian.org |http://www.{python,debian,gnu}.org
Continue reading on narkive:
Loading...