file.read() doesn't read the whole file

[R. David Murray]

Sreejith K <sreejithemk at gmail.com> wrote:
> On Mar 24, 2:12 pm, Ant <ant... at gmail.com> wrote:
> > On Mar 24, 7:59 am, Sreejith K <sreejith... at gmail.com> wrote:
> > ...
> >
> > > data is the whole file, but 'less' gives only the two lines...
> >
> > From this statement (that you are using less), it appears that you are
> > redirecting sys.stdout to a file or similar - if that is the case, you
> > may need to flush or close the output file before it picks up any
> > changes.

It's not a redirect to a file.  Fuse calls the 'read' function on the
class, the read function does a 'return' of the data, and fuse passes
the data up through the OS layer to be the result of the 'read' call
made by less.

If you don't know what a fuse file system is, this all gets very confusing :)

> Yes, I did try a flush() and close on the file which is read, but the
> result is the same. I think when a read comes in fuse redirecting the
> actual path (original file) to some other file for reading causes some
> issues like this. It would be really helpful if someone help me clear
> this issue. The getattr() calls are actually called upon the original
> file (doing an os.lstat()). Does this make any effect on the 'less'
> output ?

I'm afraid we are getting beyond my level of fuse-foo here.  You'd
probably be better off finding a fuse or even fuse-python mailing list
and trying there.

If it were me, I'd start logging everything I could (take a look at
Python's 'logging' module to help you make that easy), and twidling
things.  What happens if you change what gets returned to lstat?
What happens for various sizes and contents of the '0' file?  What
happens if you use 'cat -v' or hexdump instead of less to read the file?
Run experiments until you gather enough clues to make a guess as to what
is going on, then test your theory.  Repeat until success :)

--
R. David Murray           http://www.bitdance.com