Date: Sun, 31 Jan 1999 10:35:52 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Martin Str|mberg <ams AT ludd DOT luth DOT se>
cc: DJGPP-WORKERS <djgpp-workers AT delorie DOT com>
Subject: Re: FAT32 (xstat.c)
In-Reply-To: <199901301027.LAA24499@father.ludd.luth.se>
Message-ID: <Pine.SUN.3.91.990131103533.25086O-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com


On Sat, 30 Jan 1999, Martin Str|mberg wrote:

> I'm trying to understand what's going on in libc/posix/sys/stat/xstat.c.
> In particular in _invent_inode().

Just ask any questions you have, and I will try to answer.  I wrote
most of that stuff.

> When is st_inode wider than a short int?

On FAT32 filesystems, of course.

> If that's so, then by using LONG_MAX and counting downwards should be
> sufficient to generate unique inode numbers.

Support for FAT32 means we *need* to count down.  Even if the cluster
numbers can get as high as 2^31 - 1, we still run much lower risk of
clashing with real cluster numbers when we count that way, since a
typical disk is free near the end.

Of course, as long as we don't actually return real cluster numbers on
FAT32 systems (i.e., as long as we always invent the inode there), it
doesn't matter how do we do that.

Which brings up a related question: what does `stat' return for the
inode numbers on FAT32 volume in plain DOS mode?  Under Windows it
obviously invents the inode, but I suspect it does funny things in
plain DOS, since it doesn't expect the cluster to be a 32-bit number.