Just pushed a new update to johnwcowan repo John Cowan 26 Aug 2019 13:35 UTC
Re: Just pushed a new update to johnwcowan repo hga@xxxxxx 26 Aug 2019 13:54 UTC
Re: Just pushed a new update to johnwcowan repo John Cowan 26 Aug 2019 16:20 UTC
Re: Just pushed a new update to johnwcowan repo hga@xxxxxx 26 Aug 2019 17:18 UTC
Re: Just pushed a new update to johnwcowan repo John Cowan 26 Aug 2019 18:05 UTC
Re: Just pushed a new update to johnwcowan repo Lassi Kortela 26 Aug 2019 18:11 UTC
Ports as an argument to file-info in the context of a required chase?/follow? hga@xxxxxx 26 Aug 2019 18:21 UTC
Re: Ports as an argument to file-info in the context of a required chase?/follow? John Cowan 26 Aug 2019 18:35 UTC
Re: Ports as an argument to file-info in the context of a required chase?/follow? hga@xxxxxx 26 Aug 2019 18:49 UTC
Assorted remarks on file procedures Lassi Kortela 26 Aug 2019 15:17 UTC
Re: Assorted remarks on file procedures hga@xxxxxx 26 Aug 2019 17:06 UTC
Re: Assorted remarks on file procedures John Cowan 26 Aug 2019 20:36 UTC
Real and effective uid/gid procedures in git master Lassi Kortela 26 Aug 2019 17:26 UTC
Re: Real and effective uid/gid procedures in git master John Cowan 26 Aug 2019 18:06 UTC
Re: Real and effective uid/gid procedures in git master hga@xxxxxx 26 Aug 2019 18:12 UTC
Re: Real and effective uid/gid procedures in git master John Cowan 26 Aug 2019 18:22 UTC
Re: Real and effective uid/gid procedures in git master hga@xxxxxx 26 Aug 2019 18:32 UTC
Re: Real and effective uid/gid procedures in git master John Cowan 26 Aug 2019 18:40 UTC
Re: Real and effective uid/gid procedures in git master Lassi Kortela 26 Aug 2019 18:45 UTC

Re: Assorted remarks on file procedures hga@xxxxxx 26 Aug 2019 17:06 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Monday, August 26, 2019 10:18 AM

> Thank you to both of you for the continued hard work on the drafts!

You're very welcome!  It's rewarding work.

>> I renamed `tty?` to `terminal?`.  As of now, there are no instances
>> of "tty" in the SRFI except in the command `stty` and the names of
>> Posix functions.

Unavoidably there's also errno/notty, which I found when checking my
Chibi Scheme define-library exports list.

>> In DEC OSes, device names couldn't be more than three letters long,
>> but that's long dead.

Much more likely due to the extreme premium attached to typing and
printing even a single character using a 110 baud Teletype Model 33
KSR.  Slow, and the keys required a lot of force.  See for example the
ed text editor, which had exactly one error message, "?".

> Good call.

> [ Windows, etc. ]

> Minor nits:

> [ "fifos" -> "named pipes" on which I no strong opinion. ]

> * (BTW: we don't have a pipe() procedure?)

It's only? useful in the context of forking, which is beyond the
remit of this basic POSIX SRFI?

> * The following stat fields are obscure and rarely used:
> (file-info:device file-info)    →    integer       (procedure)
> (file-info:inode file-info)    →    integer       (procedure)
> (file-info:nlinks file-info)    →    integer       (procedure)
> (file-info:rdev file-info)    →    integer       (procedure)
> (file-info:blksize file-info)    →    integer       (procedure)
> (file-info:blocks file-info)    →    integer       (procedure)

> device and inode are good to have for file uniqueness checking, but
> should we instead provide an OS-dependent uniqueness identifier
> (which on Unix can be a (device . inode) cons cell)?

See below for one way device is useful, a change signals you've
crossed a mount boundry, which can be useful for anything including
a backup that doesn't want to do that, or limiting the search space
for all hard links to an inode.

Plus this is a POSIX SRFI, I believe raw versions of struct fields
should always be supplied even if we add smarter versions like
user-info:parsed-full-name on top of the raw pw_gecos field that's
named user-info:full-name.

> nlinks is the number of hard links. Harold, do you have a use case
> for this in your backup program?

I think it's generally useful, for example if you absolutely,
positively want to kill the storage (inode) of a file, you need to get
the link count down to 1 before your final unlink system call (modulo
the file being opened by a program, one of the biggest advantages UNIX
has over Windows).  It and device and inode are absolutely required to
avoid backing up the same inode multiple times, and to write data to
the backup so a restore can Do The Right Thing.

> rdev is the device type. What does that mean - are these device
> numbers used internally by the kernel?

Per http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html

It's "Device ID (if file is character or block special).", your guess
is correct.  It was added when blksize and blocks were added, all
three are XSI extensions that I think have been universally added.

> blksize and blocks are nowadays-obscure details of the file system
> implementation. The most likely use for these is using them by
> accident instead of file-info:size.

blksize is useful for setting buffer sizes, but blocks is essential,
it tells you how much space a file is really taking up, it ignores
holes, and rounds up to whatever is the base device block size.  My
thought is that if you're going to add blocksize, you might as well
add all three, in the "struct members are the most trivial things we
can add to the API" principle.

> * directory-files -- would be clearer to call it "directory-names"
> for two reasons: 1) it's not clear whether it returns full paths or
> only the basename parts; "names" emphasizes that it's the basenames
> only. 2) "files" suggests regular files only; this is a meaningful
> distinction in some Common Lisp implementations. "names" is clearer
> that it returns all names in the directory, not just regular files.

This conflicts with the desire to keep as many procedure names the
same as scsh as possible, but your arguments to rename it are strong.

> [ "dotfiles?" in directory-files, which I have no opinion on. ]

> * Could 'delete-directory' be called 'delete-empty-directory' for
> extra clarity?

Heh, yes, that's certainly an obnoxious but vital safety feature
when at a shell level, as scsh was in part intended to provide.

Although something more like delete-directory-if-empty would be more
clear.  In any case, another deviation from scsh's name.

> A 'delete-directory-tree' procedure would be useful in a higher
> level library. When both exist, the distinction is not obvious
> unless the names are explicit.

And extremely dangerous.  My hardcore backup posture started with my
using a DECtape to get general experience in that sort of thing, just
before I learned the -rf arguments to rm.

> * call-with-temporary-filename has "temporary" in the name; all the
> other tempfile definitions just say "temp".

create-temp-file is inherited from scsh, temp-file-prefix is the
SRFI-170 version of scsh's fluid variable *temp-file-template*,
call-with-temporary-filename is a SRFI-170 original.

> [ (read-symlink fname [override?]) ]

- Harold