svn commit: samba r25689 - in
branches/SAMBA_4_0/source/torture/raw: .
ronnie sahlberg
ronniesahlberg at gmail.com
Thu Oct 18 09:15:48 GMT 2007
On the other hand,
a solaris client will be VERY careful and not ask for READ to go
beyond the end of file and potentially might for this reason ignore
the eof-flag since that flag becomes a bit pointless for a client
that keeps track of what a previous GETATTR told about a filesize.
I had reason to investigate how HPUX handled this flag and
read-beyond-end-of-file-requests
when I had to troubleshoot why a non-linux nfs server made soem hpux
boxens really really unhappy. I unfortunately no longer have access
to the tools i wrote to test and document which clients honour the
eof-flag and which clients avoid reading beyong-eof by using the
GETATTR filesize data. :-(
>From memory I know how hpux (all versions), aix (only had access to
old versions) solaris and linux behaved. we didnt care about any
other versions really.
On 10/18/07, ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
> yes HPUX will (and also really old versions of AIX (no idea about
> recent versions) ) do this since they appear to ignore what is stated
> in GETATTR and instead rely on the read-reply-eof flag.
>
> Which is perfectly fine and valid and perfectly well documented in the standard.
>
>
> It is just different from how solaris clients works and homegrown
> servers sometimes can get "surprised" if a client does not behave
> exactly like solaris does :-)
>
>
>
> Whether or not hpux clients and old aix clients are worth worrying
> about in this day and age is a different question...
>
>
> On 10/18/07, tridge at samba.org <tridge at samba.org> wrote:
> > Ronnie,
> >
> > > So if a file is reported as 5 bytes and the nfs blocksize is 8kb,
> > > solaris, linux, bsd will do a read of only 5 bytes from offset 0
> > > while hpux and (at least old versions of) aix will do a request to
> > > read a full 8kb from offset.
> >
> > Will any of them read any bytes if the file size is zero?
> >
> > Cheers, Tridge
> >
>
More information about the samba-technical
mailing list