jra_samba_org

Sorry to keep laboring the point :-) but the other reason I'm pretty sure this is a client bug is that the client doesn't truncate the returned file at the end of the short read, which you'd expect if it actually was treating short read as EOF.

If you copy a 100mb file and the server returns a short read somewhere in the middle of the read stream the file size on the client is still reported as 100mb, which means file corruption as the data in the client copy isn't the same as what was on the server.

That's how this ended up getting reported to us in the first place.

Whenever a client gets a short read it needs to issue a request at the missing offset if the caller wanted more bytes. Only if the server returns zero on that read can it assume EOF and concurrent truncation.

We're going to have to fix the Samba server to never return short reads when using io_uring because the clients with this bug are already out there. But if what you're saying is how Microsoft expects the protocol to operate then it needs to be documented in MS-SMB2 because I don't think it's specified this way at the moment.

Well pread/pwrite have the same return values, and historically for disk reads they block or return a device error.

pread only returns a short value on EOF.

Yeah, I've gotten to the point where I can't do any arithmetic on any values without immediately adding integer wrap tests afterwards.

The Orville is the spiritual successor to TNG in my opinion.

If you can get past the somewhat juvenile humor in the early episodes it's surprisingly good.

Please don't call Samba.tv just 'Samba'. We (the Samba project) have trademark on Samba, which is for the file server, authentication and print server that runs on Unix boxes and allows interoperability with Microsoft Windows.

Samba.tv is... Something else. It has nothing to do with us.

There are several cloud filesystem gateway appliances that contain considerable proprietary code on the appliance, and use Samba GPLv3 software to provide gateway services from SMB clients into the cloud.

I'm not at liberty to name them as I am the NAS boxes as most of them are not forthcoming about their use of Samba to anyone but their customers (to whom they provide replaceable source code of course), whereas the NAS vendors are well known users of GPLv3 Samba.

You seem to be under the impression that avoiding GPLv3 code prevents competitors from buying our box and rendering it down to components, including your precious software, and figuring out any trade secrets you may have.

This is a strange and incorrect impression.

If you genuinely want to use Samba in your proprietary appliance, email me (I'm easy to find). I help companies do this every day as part of my job.

You won't be able to use Samba outside of the terms of GPLv3 of course, but most companies not requiring DRM seem to be perfectly comfortable with that.

By "signed" do you mean a DRM-locked down platform ? There's no problem with signed code, there is a problem with trying to claim ownership of a device that the customer owns :-).

There are many appliances shipping with GPLv3 Samba, Netgear, Drobo, IOmega, Synology, just off the top of my head.

Of course none of these are trying to control what the customer does with the appliance.

If you want to control what customers do with their own hardware, write your own SMB3 server. Good luck with that..

No, polshaw sounds like he has religious reasons against GPLv3 (as do Apple :-).

There are many people shipping Samba on an appliance containing proprietary software, there is no problem doing that with GPLv3 code.