Return file type from readdir

[sourcefrog]

Continuing the thread from #12 and sourcefrog/conserve#174.

In a tree that might have symlinks I'd want an option to open files with O_NOFOLLOW on Linux. (It's in Nix and libc; it doesn't seem to be in std?) (I filed #14.)

If the entry is a symlink, that will fail with ELOOP. I could then try to read it with readlinkat. If it then changes back to a file, readlinkat will give you an error.

I don't think I see the harm in DirEntry giving you an indication of the file type so that you know where to begin. There is a chance of a race, that when you read the dir it's a symlink and then it changes to be a file, or vice versa. But the worst that happens is that the call you use to read the file or link will fail. So I don't think the race is meaningful?

A different approach would be to begin with open O_PATH on Linux, and then you can stat it, find out what type of thing it is, and then proceed to either "really open it" or read the link. In this case you only pass the filename once, which seems nice.

O_PATH seems to be Linux specific https://stackoverflow.com/q/61337371.

This also seems to need more syscalls. The arguably straightforward way is

1. getdents gives you the name and tells you it's a real file
2. open the file (with O_NOFOLLOW)
3. (do stuff then) close

If readdir does not tell you the type, on Linux, you can do

1. getdents
2. openat O_PATH
3. fstatat tells you what you opened is a file
4. openat "" on that path fd to actually open the file
5. close the O_PATH fd
6. (do stuff then) close the second fd

This just seems like more steps though.

On non-Linux Unix... actually I don't see how you can do anything other than attempt to open it or readlink it? But you might as well have a clue which of them is going to work?

[rbtcollins]

O_PATH isn't widely portable, though FreeBSD has adopted it too.

I'm ok copying file type data across in next() as well. I'd like to support O_PATH flows for OS's that support it (Windows, Linux, FreeBSD) too, but I'm not sure yet what a good abstraction across having/not having it would be.

Perhaps something like
OpenOptions.open_entry(e) which can then provides a place to encode NO_FOLLOW if desired.