This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author markshep
Recipients
Date 2006-05-03.10:38:20
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=1512331

Thanks for closing this bug without giving me a chance to
follow up!

The problem isn't caused by a limitation of my machine -
it's got 3 GiB of RAM.

I've done some more testing on this and the problem only
appears when connected to a server running certain SMB
implementations:

  The local Windows XP machine
  A remote Windows XP machine
  Samba 3.0.22 on Linux

When connected to servers running the following SMB
implementations the problem isn't present:

  Windows NT 4.0 Server
  Windows Server 2000
  Windows Server 2003 Standard Edition

As this error is being returned by the underlying fread()
call the proper place for it to be fixed is there, but the
chances of Microsoft doing so for Windows XP are negligible.

As you're trying to provide a cross-platform language then
having to put up with OS's undocumented warts is just part
of the job.  As it's entirely possible for you to implement
a work-around for this problem Python I think you should. 
One of reasons for using a high level language like Python
is to be insulated from system quirks likes this.  If you're
refusing to smooth over these quirks where possible then
you're undermining that reason.

The documentation for Python's read() method on a file
handle already says "Note that this method may call the
underlying C function fread() more than once", so this
possibility is already catered for in the documentation.

As this problem only affects remotely mounted filesystems
the workaround need only be used for such filesystems.  You
can determine whether or not a drive is a network one by
using the GetDriveType() Windows call.
History
Date User Action Args
2007-08-23 14:39:43adminlinkissue1478529 messages
2007-08-23 14:39:43admincreate