5

I want to use std::filesystem to query about a disk folder path that was given to my function. I want to find out if I have write access to the folder. But I want to do it without actually trying to write to the folder.

This last requirement is partly because

  • a) I don't want to change the filesystem's last-written-to time on the folder
  • b) I want to learn how to do this merely by querying the filesystem in some sort of platform-independent fashion, if possible

It would appear that std::filesystem::status() is the function that I want. However the permissions flags returned by that function include owner_write, group_write and others_write.

How do I tell which of these applies to me? I don't know if my application/user is the owner, the group or the "other". Is there some sort of can_i_write_to_this_folder() function kicking around somewhere?

The only thread I could find related to this has no answer that involves <filesystem>

[Edit] People appear to be under the impression that I'm looking for some unrealistic guarantee of write-ability. I'm not. I'm not under the illusion that any filesystem function is foolproof. I'm not basing some mission-critical system upon this decision

When <filesystem> came around and gave us all directory_iterator and other goodies, their advertised purpose was useful. So I evaluated them and used them, when I found that to be true. Just as I did for std::atomic<> and parameter packs and std::variant and a host of other things. I think we can all agree there are a few things added over the years that have proved not to be that great.

Now the library advertises this function, filesystem::status() that purports to tell us (among other things) the permissions on a file or folder. I want to find out if this "access" information is of any practical use.

The consensus seems to be that it is not.

Joe
  • 5,394
  • 3
  • 23
  • 54
  • 4
    This is very similar to [this discusssion](https://stackoverflow.com/questions/71785809/) from yesterday (only that one was about readability instead). "*I want to do it without actually trying to write to the folder*" - Sorry, but the *best* option is to attempt to write something, and see if it fails. There is too much going on behind the scenes to do anything else. Permissions alone is not enough to check. – Remy Lebeau Apr 08 '22 at 16:28
  • 1
    Consider the case where you have permissions to write but there is no space. – Marshall Clow Apr 08 '22 at 16:37
  • @MarshallClow if that becomes a concern I could call `std::fileystem::space` – Joe Apr 08 '22 at 16:39
  • And between the checking of space and the writing of the file, someone fills up the space. You just can't win. – user4581301 Apr 08 '22 at 16:42
  • 2
    Fortunately for me, that's not a realistic concern. I'm not trying to prepare for every possible contingency here. I'm just trying to find a platform independent way of checking this one thing that doesn't alter the thing it is inspecting – Joe Apr 08 '22 at 16:49
  • @Joe - in the presence of these battle-tested suggestions, you may want to [edit] your question to clarify that you understand that this check would offer no guarantees at all. If that is an accurate assumption. That it's impossible to check if you _have_ write access - you can only check if you recently _had_ write access. – Drew Dormann Apr 08 '22 at 16:57
  • @DrewDormann I'll be happy to do that, but I assumed it was obvious. There are no guarantees anywhere ever in filesystem code. Look we have a standard function, `filesystem::status()`. It purports to tell us something useful about the filesystem. I want to see if I can find out a way to use it to that end. That's all. – Joe Apr 08 '22 at 17:01
  • Sorry Joe, I'll try again: What do you plan to do if your access check (assuming someone can come up with one) succeeds but then, when you try to write to the directory, access is denied? It seems reasonable (and perhaps user-friendly) to me to perform a check like this if one has a suitable fallback. – Paul Sanders Apr 08 '22 at 17:12
  • 2
    @PaulSanders I plan to return a more timely (and, one hopes, informative) error than I might get from a `std::filesystem::error` exception thrown some time later (when the first attempt to write to the folder might occur). I typically make a few such status checks at initialization time. If I feel I *must* fallback to just trying a dummy write and seeing what happens, I'll do it. But then that begs the question: What is even the point of the library giving us this "information" when there's nothing useful to be done with it? It's not information at all. – Joe Apr 08 '22 at 17:41
  • 3
    In that case, I'd go with [`access`](https://man7.org/linux/man-pages/man2/access.2.html), as recommended in the question you linked to. That performs more useful checks than the underlying `stat` call that `std::filesystem::status` depends on and at least you can inspect `errno` if `access` fails. It's pretty portable, even Windows has it (although they've renamed it `_access`, unfortunately), so why not? – Paul Sanders Apr 08 '22 at 18:00

0 Answers0