[OpenAFS-devel] File Descriptor use in the vol package

[Rod Widdowson]

> It seems to me that the real issue is that in places we intermingle
> the second and third I/O families.

Thats the first problem.  Actually it's the first two problems:

1) You cannot blithely pass an FD_t into afs_read on some platforms and expect it to work.  That it currently does work on Windows
must mean that somewhere else the inverse transform is happening...

2) On some operating systems (Windows), you cannot guarantee to have files open via an FD_t and an [afs_]open  at the same time.
There are interoperability issues which mean that the second open may fail.  

(3) By extension to (2) FILE* and FD_t do not mix and match happily.

At this juncture I'm fighting shy of making any proposals, I just plan do not know the codebase well enough to do that.  

I was intending playing around with the windows compiler to see if I can use it to find all the places where (1) is currently
broken.  

With that fixed we can look at how much work it is to fix (2).  There is a potential quick and dirty solution to the places where we
know that this bites us badly in the windows server, but I suspect that that list of places will only get longer over time.

/Rod

> -----Original Message-----
> From: Simon Wilkinson [mailto:sxw@inf.ed.ac.uk]
> Sent: 26 January 2011 16:46
> To: Rod Widdowson
> Cc: openafs-devel@openafs.org
> Subject: Re: [OpenAFS-devel] File Descriptor use in the vol package
> 
> 
> On 26 Jan 2011, at 16:08, Rod Widdowson wrote:
> 
> > The vol package uses three separate types of file descriptor.
> >
> > FILE *f
> > int fd
> > FD_t
> 
> 
> I remain a little bit confused about what the problem is here, and
> what the desired cure is. What follows is an attempt to clarify
> things ...
> 
> My assumption is that having 3 different types of file descriptor
> isn't a huge problem (it would be really nice to not have int fd, and
> FD_t, but we're always going to have 2, as long as we use both POSIX
> and native I/O).
> 
> It seems to me that the real issue is that in places we intermingle
> the second and third I/O families. On Unix, this isn't a problem
> because these two families are identical. But on Windows, where we
> have our own I/O calls in ntops.c, we'll (for example) open a file
> using "normal" open(), but then unlink it using nt_unlink(). This
> causes problems because we then don't get the unlink semantics that we
> desire.
> 
> So, there are two issues to resolve. The first is that we want to
> ensure consistency of use. That is, we don't want to be explicitly (or
> implicitly) casting between FD_t and int. In fact, it would be highly
> desirable if the compiler stopped us from doing so.
> 
> Secondly, it would be really nice to not have 3 file descriptor types.
> This would entail replacing all use of the int family with the FD_t
> family. In my view, this would be best acheived by adding a platform
> independent I/O framework to our nascent opr portability library.
> 
> Or is there more to this than I realise?
> 
> Cheers,
> 
> Simon.