Windows also has vestigial CON devices ("console"). I don't know if
they're used for anything anymore (the CON filenames are just reserved).
If you say "type con" to cmd.exe (but not PowerShell) it will read lines from stdin and write to stdout; the EOF sequence is Ctrl+Z , Enter.
Nice. Have to investigate what to do on Windows, which has 3-4 flavors
of variously broken symlinks :)
Here's what I know about.
Windows shortcuts are followed only by applications that understand them, like File Explorer. Cygwin doesn't treat them as symlinks by default unless it has created them itself (it sets certain otherwise unused bits). Cygwin-created shortcuts are understood by Windows but can't be edited by Windows.
Windows hard symbolic links are like Posix hard links. They look like hard links to Cygwin.
Windows soft symbolic links are like Posix symlinks. They look lke symlinks to Cygwin
Cygwin default symbolic links are text files marked with the SYSTEM attribute, encoded in UTF-16, and starting with a magic cookie. Windows doesn't treat them specially.
* 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?.
I can live with this.
* (BTW: we don't have a pipe() procedure?)
Currently in FilesAdvancedCowan but moving to ProcessesCowan, where it will simplify things greatly.
* 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?
The classic use of nlinks is that the number of subdirectories in a directory is nlinks - 2 (for . and ..). In particular, a directory with nlinks = 2 is a leaf directory.
rdev is the device type. What does that mean - are these device numbers
used internally by the kernel?
It's a number identifying what device a device file (normally in /dev) refers to. Flush it, I'd say.
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.
That's how you figure out if you have a holey file, when size != blksize * blocks.
* 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.
+0 on this one. Directory-files is scsh-compatible and I've seen it on other Schemes too.
* 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.
The whole point of dotfiles is that they are user-defined properties of a directory. Most of the time you don't want to see them.
On Windows, dotfiles are not the canonical way to indicate hidden files;
there is a "hidden" flag in the FAT/NTFS file attributes.
On Windows, dotfiles? should respect hidden as well.
* 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.
Seems like an unnecessary change to me. It's not, I think, actively misleading.
* 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.
Yes. Cut and paste disease.
The main reason for 3-letter device names was pre-octet CPUs and the high cost of disk storage (every byte counted). Typing and printing was a secondary consideration.
On DEC's 18/36-bit systems, file names were packed 6 bits to an ASCII character (lowercase and control characters were not allowed), so 3 chars in a halfword, 6 in a fullword. That's why SCHEMER became SCHEME, though SCHEMR would have worked too.
On 16-bit systems, 3 chars from an even more limited set were packed into 16 bits: <
https://en.wikipedia.org/wiki/DEC_Radix-50>. So device names were 3 chars and files were 6 chars plus a 3-character extension (the dot was not stored explicitly). On 12-bit systems, 2 6-bit chars were packed in a word, so devices had names like DK for DSK, TT for TTY, and SY for SYS, and files were 6 chars plus 2 chars of extension.
Even after the death of RAD50, I used to use it (by hand) to generate a 2-byte magic number for binary files on Unix, based on a 3-character meaningful signature.