The umask system call which is equivalent to this SRFI's set-umask returns the previous umask (setting and resetting the umask to a saved copy is the only way to find out what it currently is...). Any reason to not change the undefined return of set-umask to return the old umask, except for scsh returning a #{Unspecific} value, which can be noted in Implementation?
Since anything permission-bits/perms related was "improved" with scsh 0.7, we can't use scsh's umask operations as good example implementations, while it's bog simple with Chibi Scheme (well, modulo I'm not sure my return values will be GCed, I have a pending authorization email to the Chibi Scheme Google Groups mailing list on that detail).
Hmmm, Chibi Scheme defaults creating directories and symbolic links with permission bits #o775 instead of the SRFI's #o777, not defaulting to world writable would be a very good idea. Ditto fifoes, except #o664 is its appropriate set of permission bits.
The following asymmetry in procedure names:
(create-hard-link oldname newname [override?]) → undefined (procedure)
(create-symlink oldname newname [override?]) → undefined (procedure)
Will no longer needed once I implement both in Chibi Scheme (due to stealing copying with full attribution from filesystem.stub, should be trivial as soon as I do the general SRFI's error system), I suggest renaming create-symlink to create-symbolic-link.
An operation missing from both R7RS and the SRFI that's in Chibi Scheme's filesystem library that I think should be added because of it's trivial implementation is rename-file. This also gives us the opportunity if we so desire to rename chdir -> change-directory and cwd -> change-working-directory.
- Harold