Re: _wstat on Windows (actually stat stuff in general)

[Ryan Lortie <desrt desrt ca>]

On Wed, 2011-09-28 at 11:03 +0200, Kean Johnston wrote:
> So easily solved. Call the damned thing g_statfile() and have the structure 
> be GFileStat.

So then we would have 'struct stat' and 'GStatBuf' which would work with
g_stat(), g_lstat() and fstat().  Additionally we would add a
'GFileStat' that only works with new calls 'g_statfile()',
'g_lstatfile()' and (presumably) 'g_fstatfile()' (for fstat()
functionality applied to the new structure type).

My head is spinning...

> Only if you define "UNIX" as "Linux". OSX has other fields Linux doesn't. 
> Some UNIX variants have 16-bit uid_t's others have 32. Some have as low as 
> 16-bit ino_t's others have 64. There are all KINDS of ways in which it 
> differs. Offering a portable, no-ifdefs-required, 
> suitably-large-sized-to-accomodate-everyone structure ... yes *STRUCTURE* 
> that all code can use completely portably without having to worry about 
> anything ... SURELY you can see the value in that? GFileInfo from GIO? You 
> have GOT to be kidding me? As a replacement for stat()? When I want to look 
> up a file attribute I have to go through hash table lookups for attributes 
> and a completely open-ended size (GArray *attributes) and all that parent 
> class and instance overhead - versus having a single structure I can 
> sizeof() and write to a file? In what universe is that a better approach?

I don't find the ability to write 'struct stat' to a file to be a
particularly compelling usecase...

You propose to avoid indirection by moving people away from GFileInfo to
GFileStat.  At the same time, you'd be adding more indirection to the
g_stat() users though -- a copy of all of the various fields of the
system native structure to our shadow structure.

Unless you actually propose that we keep both APIs around and
undeprecated -- and my head is spinning again....

I don't really appreciate the problems that are caused by different
sized inode, uid, etc. fields...  It might be unsightly or aesthetically
displeasing on some level, but the something like:

  if (buf.st_uid == getuid()) ...

will obviously always work properly.  I think, if anything, we cause
ourselves more trouble by breaking with the system definition.

The only benefit to your proposal (from a UNIX standpoint, at least) is
that it helps avoid accidental portability problems where a non-portable
field is used.  I'm not sure that it's worth all the drawbacks.

Cheers