File type nomenclature in 170
Lassi Kortela
(31 Jul 2020 11:11 UTC)
|
||
(missing)
|
||
Re: File type nomenclature in 170 Lassi Kortela (31 Jul 2020 11:44 UTC)
|
||
Re: File type nomenclature in 170
John Cowan
(31 Jul 2020 15:21 UTC)
|
||
Re: File type nomenclature in 170
Lassi Kortela
(31 Jul 2020 15:45 UTC)
|
||
Re: File type nomenclature in 170
hga@xxxxxx
(31 Jul 2020 16:13 UTC)
|
||
Re: File type nomenclature in 170
Lassi Kortela
(31 Jul 2020 16:25 UTC)
|
||
Re: File type nomenclature in 170
Lassi Kortela
(31 Jul 2020 16:36 UTC)
|
||
Re: File type nomenclature in 170
hga@xxxxxx
(31 Jul 2020 16:59 UTC)
|
Point 3, identifying a file's type. We do it with these predicates: (file-info-directory? file-info) POSIX S_ISDIR() (file-info-fifo? file-info) POSIX S_ISFIFO() (file-info-symlink? file-info) POSIX S_ISLNK() (file-info-regular? file-info) POSIX S_ISREG() If these are kept, we should add `file-info-socket?` and `file-info-device?`. I would replace these with a single procedure: (file-info:type file-info). It would return a symbol that is one of: - file (regular files only) - pipe (named pipes and anonymous pipes, which Unix says are same) - socket (local-domain, internet, etc. sockets, all are one to Unix) - device (block and character devices, are the same on some kernels) - directory (speaks for itself; also Windows drives are dirs) The equivalent WinAPI ones from <https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants> are: - FILE_ATTRIBUTE_DEVICE - FILE_ATTRIBUTE_DIRECTORY - FILE_ATTRIBUTE_REPARSE_POINT (one of the weird symlink emulations) - other ones are regular files Ruby's `ftype` method classifies files like I suggest above (<https://apidock.com/ruby/File/ftype/class>): one of “file”, “directory”, “characterSpecial”, “blockSpecial”, “fifo”, “link”, “socket”, or “unknown”. Really the character-special vs block-special distinction is pretty moot at this point. FreeBSD hasn't had block devices in years. Windows only has "devices". And people who care about block vs character devices can always go fishing in the raw bitfield from `file-info:mode`. The word "special" (as opposed to "device") is also confusing and I think we shouldn't promulgate it. Here's a demo program that shows Unix thinks named pipes (FIFOs) and anon pipes are the same in this respect as well: ---------------------------------------------------------------------- #include <sys/types.h> #include <sys/socket.h> #include <sys/stat.h> #include <arpa/inet.h> #include <netinet/in.h> #include <stdio.h> #include <unistd.h> #define NAMED "our-named-pipe" static struct stat st; static int classify(const char *which, int stat_retval) { int is_pipe; if (stat_retval == -1) return -1; is_pipe = (st.st_mode & S_IFMT) == S_IFIFO; printf("%s %s\n", which, is_pipe ? "is a pipe" : "Ceci n'est pas une pipe."); return 0; } int main(void) { int fds[2]; if (pipe(fds) == -1) return 1; if (classify("anon pipe reader", fstat(fds[0], &st)) == -1) return 1; if (classify("anon pipe writer", fstat(fds[1], &st)) == -1) return 1; if (mkfifo(NAMED, 0600) == -1) return 1; if (classify("named pipe", stat(NAMED, &st)) == -1) return 1; return 0; } ---------------------------------------------------------------------- Here's a comparison of named pipes on Unix and Windows: <https://en.wikipedia.org/wiki/Named_pipe>