Re: [Chicken-users] S_IFMT constants

[Alaric Snell-Pym]

Peter raised an interesting point on IRC - doesn't stat-regular? et al
do this? The stat-*? functions all take a file name, call stat, then
examine the mode of the result to see if it has the specified type.

Which makes them a bit redundant with directory? et al.

How did this come about? It would have made more sense for stat-* to
accept a stat-obtained file mode and work on that than a filename that
they, themselves, stat. Why the duplication with directory?, symlink?
et al?

Is anybody actually using stat-*?, or should we change them to operate
on file modes?

Also, I have developed a few more requests for the posix unit needed
to implement Ugarit, my backup system, which I shall implement myself
and duly submit code for inclusion if people approve, and nobody
points out already exist somewhere:

1) utimes and lutimes, which set the mtime and atime on things (with
the l- version operating on, rather than through, symlinks)
2) similarly, l-prefixed versions of chmod and chown, so I can set the
attributes of symlinks
3) mknod, so I can restore character and block device files!

So far, my backup system backs up files, directories, fifos, symlinks,
and block and character device files, and records contents, mtime,
ctime, atime, mode, uid, and gid of each, but can only restore files,
directories, fifos, and symlinks - and only restore contents, uid,
gid, and mode.

I've now used up my "2 day" estimate to produce the thing, but I hope
to not spend more than a couple more hours tidying up those rough
edges and then writing a command-line wrapper around it to do
snapshots and restores, then I'll give it a very thorough test on a
large filesystem and release it to the public. I plan to see if I can
make a tarball that contains all the C sources, even for the eggs I
use, so it can be made available to chicken-less people.

388 lines of that are unit tests and testing tools, too ;-) I have 89
lines of local-filesystem storage backend, 63 lines of caching storage
backend wrapper, and 622 lines of core algorithms, for a total of 774
lines of code that does real work.

The fact that it looks like I'll manage to build a powerful,
efficient, reliable backup/archival system in about two days, in under
a thousand lines of code, is a testament to the elegance of Scheme!

As a case in point, this project has taught me the elegance of fold.
I'd always thought that fold looked a bit of a useless function;
having read about it, I had a mental note to look it up next time I
had to sum the elements of a list or something, until I spotted gdbm-
fold in foof's gdbm egg (while writing the cache backend wrapper).
That use of the fold 'pattern' to iterate over a database sort of
clicked in my head, and I ended up writing my fundamental operators to
iterate over large structures in Ugarit as folds, rather than the less
elegant for-each I originally had in mind. Fold on!

ABS

--
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/?author=4