I think adding read-symlink would be sufficient for the sorts of backup programs I want to write, which therefore wouldn't be portable to Schemes that only implement SRFI-170. It's one pretty simple system call wrapper:
ssize_t readlink(const char *restrict path, char *restrict buf,
size_t bufsize);
But that's very much not a good argument: the less in the SRFI, the more people will even try to, let alone write complete implementations. Which I'm confirming is a fair amount of work, for a community that is severely labor constrained.
Which suggests we should step back at some point and decide what else is best removed.
While we're at it, we should weaken this introductory sentence for file-info, "The file-info procedure returns a file-info record containing everything there is to know about a file.", since we're consciously not doing that.
- Harold
----- Original message -----
From: John Cowan <xxxxxx@ccil.org>
Date: Wednesday, July 31, 2019 2:02 PM
Yes. I think, though, that that use case doesn't satisfy the 80-20 rule.
Date: Wednesday, July 31, 2019 1:47 PM
[...]
The read-symlink procedure seems to have disappeared in commit eadc8f82,
"editorial and minor functional changes", right after draft 3. Was that
intentional? There is no way to have the same functionality if that
procedure is not provided.
It's not clear to me that it's actually useful in typical programs, unless you want to write your own ls -l implementation. Googling around shows no one explaining the purpose of it.
This hits my major long term use Scheme case: backup programs, where you must capture a great deal of information about all file objects.
On the other hand, quite a bit more is needed for certain types, or should I say qualities, of backups, vs. a tar equivalent:
etc.