Logical how? If you want that, you can just as well use file_stat directly then.

But what problem do you really want an answer to? If you want to know that you will create a new file (if possible) by writing the file name, this seems to be the normal behaviour.

Actually, Stdio.File(..., "wcx") doesn't work on a dangling symlink. Another case is rm() which shouldn't fail with System.ENOENT if and only if it exists. Yet another is mv() which can move a dangling symlink perfectly fine.

So the query makes sense in many situations. But above all I want the most natural behavior given the function name, and instinctively I think even a dangling symlink really do exist - it affects its surroundings by showing up in directory listings, it got a pointer, owner and group that can be queried, etc.

I think it should. It's a common (?) operation that is called what you actually want to do (or rather find out).

Besides clearer code, some (future or past) operative system it might be a cheaper operation than a stat, and could be optimized.

It totally beats switching on file_size, anyway. XD

It depends. A symlink is like a tunnel. It exists, then again it doesn't because a tunnel is merely an open space you can walk through; in fact a tunnel is defined by what isn't there.

Philosophical issues on the Pike mailinglist...

Yes, but can you call a tunnel which has no endpoint (i.e. dangling symlink) still a tunnel?

is it like a door that leads to nowhere?

Which is precisely where this string of similes seem to lead.

Ok, let's say a symlink is like a door. I suppose a regular file would be like a box, and a directory could be like a shelf.

Now, given that exists() returns true on a box and a shelf, what should it return for a door with a wall behind it? I don't see it as very enlightening...