开发者

Can't get Python to read until the end of a file

I have tried this a few different ways, but the result always seems to be the same. I can't get Python to read until the end of the file here. It stops only about halfway through. I've tried Binary and ASCII modes, but both of these have the same result. I've also checked for any special characters in the file where it cuts off and there are none. Add开发者_如何学Pythonitionally, I've tried specifying how much to read and it still cuts off at the same place.

It goes something like this:

f=open("archives/archivelog", "r")
logtext=f.read()
print logtext

It happens whether I call it from bash, or from python, whether I'm a normal user or the root.

HOWEVER, it works fine if the file is in the same directory as I am.

f=open("archivelog", "r")
logtext=f.read()
print logtext

This works like a dream. Any idea why?


The Python reference manual about read() says:

Also note that when in non-blocking mode, less data than was requested may be returned, even if no size parameter was given.

There is also a draft PEP about that matter, which apparently was not accepted. A PEP is a Python Enhancement Proposal.

So the sad state of affairs is that you cannot rely on read() to give you the full file in one call.

If the file is a text file I suggest you use readlines() instead. It will give you a list containing every line of the file. As far as I can tell readlines() is reliable.


Jumping off from Kelketek's answer:

I can't remember where I read about this, but basically the Python garbage collector runs "occasionally", with no guarantees about when a given object will be collected. The flush() function does the same: http://docs.python.org/library/stdtypes.html#file.flush. What I've gathered is that flush() puts the data in some buffer for writing and it's up to your OS to decide when to do it. Probably one or both of these was your problem.

Were you reading in the file soon after writing it? That could cause a race condition (http://en.wikipedia.org/wiki/Race_condition), which is a class of generally weird, possibly random/hard-to-reproduce bugs that you don't normally expect from a high-level language like Python.


The read method returns the file contents in chunks. You have to call it again until it returns an empty string ('').

http://docs.python.org/tutorial/inputoutput.html#methods-of-file-objects


Ok, gonna write this in notepad first so I don't press 'enter' too early...

I have solved the problem, but I'm not really sure WHY the solution solves the problem.

As it turns out, the reason why one was able to read through and not the other was because the one that was cut off early was created with the Python script, whereas the other had been created earlier.

Even though I closed the file, the file did not appear to be fully written to disk, OR, when I was grabbing it, it was only what was in buffer. Something like that.

By doing:

 del f

And then trying to grab the file, I got the whole file. And yes, I did use f.close after writing the file.

So, the problem is solved, but can anyone give me the reason why I had to garbage collect manually in this instance? I didn't think I'd have to do this in Python.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜