[OpenAFS-devel] Re: Avoid mixed use of Win32/CRTL in the servers
Jeffrey Altman
jaltman@your-file-system.com
Tue, 18 Jan 2011 14:25:21 -0500
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0FD6D3D417EA4A8EC587BE96
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 1/18/2011 2:09 PM, Andrew Season wrote:
> On Tue, 18 Jan 2011 18:36:41 -0000
> "Rod Widdowson" <rdw@steadingsoftware.com> wrote:
>=20
>> Mixing CRTL IO and Win32 is a recipe for disaster, and I have been
>> looking at the servers with a view to reducing this.
>=20
> CRTL is... C Run-Time Lib? I suppose CRTL I/O is e.g. open() and Win32
> I/O is some CamelCase family of functions?
On Windows the C Run Time Library functions such as fopen() and open()
are implemented using a very restricted set of Win32 APIs CreateFile,
ReadFile, WriteFile, CloseHandle, etc. and modes such that not only is
performance horrible but the currently documented functionality can't
possibly work. For example, in namei_ops.c, there are a couple of
locations where it is stated that nt_unlink() is used in order to permit
a file to be marked for deletion while it is in use. Since the file is
in use as a result of an fopen() or open() CRT library call, it is not
possible to mark the file for delete on close. This is because those
libraries do not call CreateFile() with the DELETE privilege and
FILE_SHARE_DELETE lock option.
The conversion from fopen() and open() to nt_open() and related
functions is the next step at producing a Windows file server that can
scream.
>> 1) Redirect IO through the afs_XXXX operations. =20
>=20
> Not OS_OPEN &co?
I do question why we have both. In both cases the macros refer to
nt_open() on Windows.
Jeffrey Altman
--------------enig0FD6D3D417EA4A8EC587BE96
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iQIcBAEBAgAGBQJNNekjAAoJEPd6c1WStpoEvkEP/3+LADsT4rVjZLI7gb1O2mlA
txPsJ05yGXV8C9T6LOgCT1kQv7p18XwmMAUTi1x9CeaXdmfOGQlGXoJm+JxxbPLC
v2R4AlzE0h2dCNv6R4ZOSk903geotXGoshoWPvE3lit3E4sC1eJSeMMY4n4KXNi3
v5v3+L493TdkHN2yaaeAOvb65my6C4Ll6ibVfQkinIIcrB9wyrW4fd1xCeyq2mt0
8EbO69BiWqhfo9FRSganhz/5LEz29WiF1PP1UW/NeqEdq7gNX5kXNGtVkKedGPhL
zE2POqbZeQ35K8YFGTjKIUZpuuUyCZy+cdEASFHf0TKAYw6CA3sKpmXEc4yo+Par
vBp3OpK08rTUXkdHHf48QCY7DVQrjzE/lNoB0VgK4M1QbEr+FkLncxXUPAWuN4vS
SNx+1l5GvrunD5DSiALKBTo7lO9J1uoyUhQCty4jCGOdXu+L8jPU4YjI26EtET5t
dzD0EsJhTwZCjoEM353+CpxXNRgGztbZZ7rsBCHf10dXiU5hQuzcOcCQXMCKZ/3r
1d7Xc6Y21oSee/ZimU855qZ1qQfKfYeQuDbnYBNpOwy3WbnfOwtleCMRgcnt6dD6
PVPvw8v5A7yYJfHQvv/NThCVqJbXo0oR+KsGJlqdlNyTrdmXgqA0TTJEE2yXdDD9
opoeGHn4He+uitfB3KMb
=0dD3
-----END PGP SIGNATURE-----
--------------enig0FD6D3D417EA4A8EC587BE96--