Assorted remarks on file procedures Lassi Kortela 26 Aug 2019 15:17 UTC
Thank you to both of you for the continued hard work on the drafts! > 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. In DEC OSes, device names couldn't be more than three > letters long, but that's long dead. Good call. Windows also has vestigial CON devices ("console"). I don't know if they're used for anything anymore (the CON filenames are just reserved). > I have concluded that control of symlinks does meet the 80-20 > limitation, especially as implementation is trivial. So I have added > back `create-symlink`, `read-symlink`, and `file-info-symlink?`. Nice. Have to investigate what to do on Windows, which has 3-4 flavors of variously broken symlinks :) > I've also merged hga up to date. Unless there are major objections to > the substantive changes, I'll do a PR for Arthur (it'll take him a while > to get to it; he's swamped). I like the way it's going. Just noticed that the directory and timespec objects/procedures are specified makes it possible to use them with directory ports and opaque time objects as in Gambit. That's great. Minor nits: * I would talk about "named pipes" instead of FIFOs. Everyone knows ordinary (anonymous) pipes, so by emphasizing that FIFOs are just a named variant of the same, there are fewer words for the same thing. Windows API documentation also talks about "named pipes" (https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipes). So the procedures would be create-named-pipe and file-info-pipe?. * (BTW: we don't have a pipe() procedure?) * 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)? nlinks is the number of hard links. Harold, do you have a use case for this in your backup program? rdev is the device type. What does that mean - are these device numbers used internally by the kernel? 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. * 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. * I still think dotfiles? is arbitrary, and it's misleading that the default is false, but it's your call. I would leave dotfile filtering to higher-level code such as a (glob) procedure or a (ls) user interface. On Windows, dotfiles are not the canonical way to indicate hidden files; there is a "hidden" flag in the FAT/NTFS file attributes. * Could 'delete-directory' be called 'delete-empty-directory' for extra clarity? 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. * call-with-temporary-filename has "temporary" in the name; all the other tempfile definitions just say "temp". * (read-symlink fname [override?]) -- the override argument is included here by mistake.