In an OO model, you can implement exactly that by having FILE and DIR derive from a common base class, then you can have your function take such a base and either act on the common subset or do a type query and cast to the derived type as needed (this is usually frowned on, but not uncommon).
But yes, of course shoving everything under OO is bad. A bit of OO should be a mean to an end, not a inflexible design principle.
> you can implement exactly that by having FILE and DIR derive from a common base class
Ah, but now you're changing the problem :) we are not in C++, we do not have base classes, we are in C and have just two so-called objects. They don't belong to us, they're exposed as part of an API.
To recap, objects are entities that bind together data and functions. You can't have a single function belong to two objects, by definition.
Some people say that FILE and DIR plus the associated functions are objects; even though there's no syntax for it, they are objects conceptually, it's supposedly the same thing.
But if FILE and DIR are 2 conceptual/imaginary objects, to which of the objects does F(FILE, DIR) belong?
And, given they're not real objects, the answer can be whatever you want it to be.
You can say that in this scenario they stop being objects at all, or you can say FILE owns the function because it's first (but then about the encapsulation, why does F use the internals of both), or you can say conceptual objects can be conjoined like siamese twins, or whatever you feel like it. You can say the set of all functions that take an int is an object. Once you go down this road, you can say anything is OOP if you look at it in a certain light.
I understand that people can/do apply the OOP mindset to anything, it's their choice. But I don't think it's fair to characterize C as OOP since it doesn't even have syntax for objects. Syntax is real, people's mental models are not. But that's just me.
Unless you are the most fervent single-dispatch OO cultist, there is no expectation that a function F(FILE, DIR) need to belong to a specific object (otherwise you could literally not have anything but unary function). And with multiple dispatch (a feature for example of CLOS), it can in practice belong to both).
FILE is definitely OO object flavored: it is an opaque handle that encapsulates state and behavior through a generic runtime-dispatched interface. The biggest issue is that it is not open to user extension (except for the nonstandard fopencookie).
As an aside, you can of course have the moral equivalent of base classes in C. See for example the POSIX sockaddr class "hierarchy".
edit: to be clear, I'm in no way claiming that OO invented this stuff. I'm sure people where building the moral equivalent of vtables before Simula. OO just gave us a language to discuss this sort of features, which is useful. It also came with a lot of philosophical baggage and design guidelines (Everything is an object!), which IMHO are less so.
I suspect that, rather than give us a language to discuss these features, OO hijacked the programmer jargon with its own terminology and heavily marketed it to become the default.
To the point where FILE is called an object, even though it's just an opaque pointer hiding the implementation. It can be phrased in OO terms but this irks me because it sounds as if OO invented it (I know you're not claiming this), and anything non-OO ("procedural, yuck") is bad. Which leads to the "everything must be an object" mindset that so many programmers exhibit today.
Which is why it bothers me to see "OOP with ANSI C". To me, those are just more or less normal patterns in C, why call it OOP when it's normal procedural code :) that's just me. Rant over.
But yes, of course shoving everything under OO is bad. A bit of OO should be a mean to an end, not a inflexible design principle.