Proper way to test for readability/writability of a folder
Solution 1
The foolproof way to check permissions is to literally check the file mode. In the case of directory permissions, the meaning of "readable" and "writable" might be surprising:
- Read - allows you to list the contents of the directory
- Write - allows you to create, rename, delete files from the directory, essentially modifying the list of contents (also requires execute)
- Execute - allows you to access (both read and write) and change properties of files within the directory
So if you have a directory with just the execute bit set, you can still read and write to the files inside. By turning the execute bit off, you can disable access to the files. As far as the contained files are concerned, the most you can figure out from the directory permissions is:
-
--x
orr-x
: existing files can be read and written to -
-wx
orrwx
: existing files can be read and written to, files can be created, renamed and deleted - otherwise: you have no access to the files at all
To determine if a file is readable but not writeable (or vice versa) you need to check the permissions of the file itself. The directory can only tell you if the files can be accessed in general.
You can use stat() or access() (see BЈовић's comment) to find out the permissions for a file or directory. Since you're already using boost, you can also use boost::filesystem::status() which simply wraps stat().
Solution 2
To be portable and correct, the only way to test for readability/writability of a file/directory is to read/write from/to it. Permission models can be quite complex and non-portable (ACLs for example), so you can't simply check the permissions on the parent directory. Also, checking, and then subsequently trying to write is a race condition as the permissions could change between the check and the write.
If instead what you want is a high probability that a write will succeed, such as if you're letting the user choose a scratch folder for your application, just try writing a file and then delete it afterwords. This lets you know that at the time of user selection the directory was writable.
To be robust, always assume that filesystem operations are going to fail and design so that when they do, something logical will happen instead of a crash. In particular, design a system so that a user can figure out where the permission error is -- as there's a myriad of ways permissions can be set wrong, helpful error messages go a long way.
Related videos on Youtube
unludo
Updated on September 15, 2022Comments
-
unludo about 1 year
I have written a function to test for the readability/writability of a folder.
For unit testing it, I need to produce the different cases:
- a folder with readable and writable files
- a folder with readable files (not writable)
- a folder not writable and not readable.
Here is the code for the function I came to, up to this point:
void FileUtils::checkPath(std::string path, bool &readable, bool &writable) { namespace bf = boost::filesystem; std::string filePath = path + "/test.txt"; // remove a possibly existing test file remove(filePath.c_str()); // check that the path exists if(!bf::is_directory(path)) { readable = writable = false; return; } // try to write in the location std::ofstream outfile (filePath.c_str()); outfile << "I can write!" << std::endl; outfile.close(); if(!outfile.fail() && !outfile.bad()) { writable = true; } // look for a file to read std::ifstream::pos_type size; char * memblock; for (bf::recursive_directory_iterator it(path); it != bf::recursive_directory_iterator(); ++it) { if (!is_directory(*it)) { std::string sFilePath = it->path().string(); std::ifstream file(sFilePath.c_str(), std::ios::in|std::ios::binary|std::ios::ate); if (file.is_open()) { size = file.tellg(); if(size > 0) { memblock = new char [1]; file.seekg (0, std::ios::beg); file.read (memblock, 1); file.close(); delete[] memblock; if(!file.fail() && !file.bad()) { readable = true; } break; } } else { // there is a non readable file in the folder // readable = false; break; } } } // delete the test file remove(filePath.c_str()); }
Now with the tests (done with Google tests):
TEST_F(FileUtilsTest, shouldCheckPath) { // given an existing folder namespace fs = boost::filesystem; fs::create_directory("/tmp/to_be_deleted"); bool readable = false, writable = false; FileUtils::checkPath("/tmp/to_be_deleted",readable, writable); fs::boost::filesystem::remove_all("/tmp/to_be_deleted"); EXPECT_TRUE(readable && writable); }
I will add more for the other cases when I will have gone further.
Now the game is open to propose a better solution :-)
-
Admin about 11 yearsThe proper way is to read or write. And if you don't get permission denied error then you have succeeded. Otherwise you are running into a race condition.
-
BЈовић about 11 yearsWith access, you open a security hole. read more about it in
man access
(the warning in Notes)
-
Blacklight Shining over 10 years@unludo I find this post a bit misleading. Directory permissions do not determine permissions on the contained files at all. Regardless of what permissions you have on a directory, you will not be able to read from, write to, or execute a contained file unless you have the proper permissions on said file.
-
Matt Parkins almost 10 yearsThis is by no means foolproof either. Checking the appropriate permissions does not tell you wether a folder can be written to, it merely tells you whether a folder was writable (past tense).
-
Steve about 9 yearsWhat if the filesystem is mounted read-only? The permissions on both the mount-point and the contained files are not effected by this, and the files/directories will NOT be writable.