:: Re: [DNG] terminology
Inizio della pagina
Delete this message
Reply to this message
Autore: Hendrik Boom
Data:  
To: dng
Oggetto: Re: [DNG] terminology
On Fri, Aug 28, 2020 at 08:00:54AM +0200, Didier Kryn wrote:
> Le 24/08/2020 à 00:20, Hendrik Boom a écrit :
> > On Sun, Aug 23, 2020 at 01:55:59PM -0400, Steve Litt wrote:
> >> On Sun, 23 Aug 2020 03:19:12 -0700
> >> spiralofhope <spiralofhope@???> wrote:
> >>
> >>> On Sun, 23 Aug 2020 09:59:53 -0400
> >>> Hendrik Boom <hendrik@???> wrote:
> >>>
> >>>> Is there an establiched word in the Linux/Unix xommunity
> >>>> for something which might be a file or a directory?
> >>> Perhaps something like inode?
> >> Inode is a number used to locate a file or directory, so it's the wrong
> >> word for this purpose. I'd suggest either "file or directory", or to
> >> coin your own word (filerectory?).
> > Actually, an inode is an entry in the on-disk inode table.
> > The number is an index into that table.
> >
>     The inode only exists in the filesystem manager; the inode number
> can be obtained by userspace applications but not used for anything else
> than comparing two of them,


I've done that. But you also have to check that the files in question
are in the same file system.

> because is no IO function taking the inode
> number as input.


On Unix in the mid 1970's it used to be possible to open a file by inode
number.

> Therefore it looks to me more like an implementation
> detail than a sensible concept.


I do miss the ability to identify a directory independent of its name.
It can be important if a directory is renamed and you have active data in it.

There's one directory that works for -- the current directory. If you
rename that directory you're still in it.

In the 80's or 90's (I forget) there was a proposal to the ISO from
Japan to establish a standard OS-independent OS interface for
programmers to use. I lost against POSIX.

But it had a machanism whereby opening a file could be done in two
phases.

First you get a "lock" on a file. That gives you a connection to that
file. It's not an exclusive kind of lock (unless you ask it to be);
it's just a way of unambiguously identifying the file as long as it
exists and you keep the lock. It hangs on to the file even if someone
renames it. (not sure what happens if the file is deleted, though)

Then afterward you can open it, close it, set exclusive
read/write access, release exclusive access, etc, using the lock instead
of the name.

I've often regretted there's no such similar feature in Linux. The
assurance that several uses of a file or directory are indeed to the
same file or directory. You can do some of this by keeping a file open,
but I know of nothing like that for directories.

-- hendrik