Created attachment 26633 [details] [review]
add G_FILE_TEST_IS_READABLE, G_FILE_TEST_IS_WRITABLE, and g_file_test_full

The above patch adds conditions for testing if a file is readable or writable. 
It also adds a new function g_file_test_full which checks if all conditions are
true, instead of if any conditions are true.

We generally use _full() to mean *only* a function that takes an additional
g_destroy_notify()

g_file_test_all() or something might work.

The docs shouldn't be in two places, but instead be done as a cross-reference.

Can you provide non-broken use cases for READABLE/WRITABLE; even more than
general uses of g_file_test, these seem like to be present in code
that isn't properly checking for error conditions ... you need to check
for failure when you go ahead and do the operation, so why are you
testing first?

I'm using g_file_full_test() when searching through a list of paths (in order)
looking for a suitable file in one of them (see g_find_file_in_data_dir and
g_find_file_in_configuration_dir in bug 139973).  Those functions search each
directory in the appropriate $XDG_*_DIRS variables looking for some specified
file.  

I guess an example would be something like this:

do {
    char *filename;
    
    filename = g_find_file_in_configuration_dir("someconfigfile",
G_FILE_TEST_IS_REGULAR | G_FILE_TEST_IS_READABLE);

    if (!filename || too much time has passed) 
      error out
} while (!load_file(filename));

I agree that g_file_test and g_file_test_all make it easy to write broken code,
but I don't see how G_FILE_TEST_IS_READABLE and G_FILE_TEST_IS_WRITABLE are any
different in that respect than the other tests.

The more I think about this the less confident I get that test_all is going to
be useful.  For my sepecific example above, it seems possible that load_file
could want to impose additional constraints on the file selected that find_file
couldn't know about (constraints beyond those imposed by GFileTest).  In that
case find_file would continually return the same file each iteration of the loop
and things would screw up.  I guess adding more test conditions to GFileTest
doesn't really help the problem, because the user can always want some
constraint that isn't part of GFileTest.  

More generally, test_all doesn't make any guarantees that all the test
conditions will be true by the time the function ends (or even by the time any
of the other test conditions are checked) and that's really quite broken to
think about.

Hmm, the usecase in the xdg basedir api is to find a file with certain
properties to call some function on it. Maybe a nicer solution is to let the
find_file function take a callback and loop until it finds true.