We already have is_directory, so I think we should introduce similar functionality to is_link and is_file. Same thing for delete_file and remove_directory , we probably need unlink (or remove_link) and create_link?

Regarding this there is one thing I wanted to discuss.. in unix all the types such as S_IFDIR etc are mutually exclusive, meaning only one of the 6 types will be set, but in windows they are not, which means a file CAN have more than one attributes set... This could lead to a potential misunderstanding that just because a path is fs_type_symlink it cannot be fs_type_directory which is in fact not true, this is how directory symlinks work on windows...

So I wonder if we should go ahead with these is_ functions instead of trying to assign a unique type to a path? Also should we include more is_ functions that are not really cross platform? Like Python's os.path.is_junction

This is the way that feels most natural to me:

• regular file -> is_file = .true., is_directory = .false., is_symlink=.false., exists = type_file
• regular dir -> is_file = .false., is_directory = .true., is_symlink=.false., exists = type_dir
• link to file -> is_file = .true., is_directory = .false., is_symlink=.true., exists = type_link
• link to dir -> is_file = .false., is_directory = .true., is_symlink=.true., exists = type_link

But of course I suggest further ideas about this be discussed.

That seems reasonable @perazz, I have added is_symlink and is_regular_file.
Let me know if it looks good and I will add the specs and examples

LGTM @wassup05 @sebastian-mutz, except I is_file looks more natural to me than is_regular_file, and in line with is_directory (we don't have is_regular_dir there). What do you think?

is_file does feel better and concise, but because of the parameter fs_type_regular_file and to be consistent with that I have named it is_regular_file.. I don't have a particular preference as such

Hi @wassup05. Perhaps this consistency matters a little less than having a slightly more intuitive is_file, which users will be more exposed to? That said, I see your logic and honestly have no strong opinion either way.

Another point to discuss I feel is, should these is_ functions provide optional error handling capabilities using the usual state_type instead of just being logical?

Can you highlight some specific advantages you see in using state_type/what error handling capabilities you think would be beneficial to these?

It's the same as many other functions that have been added over time, let's say exists in this current PR itself, it takes an optional, intent(out) argument of type state_type and let's say there is some error like the many errors described here (in the ERRORS section) the err argument properly describes what happened.

The same reasoning can be applied to is_directory, is_file, is_symlink.. instead of just a plain .false as the return value regardless of any ERROR that may have occured, we could properly provide the user with the specific details of what actually went wrong.