digitalmars.D - Check if a File/DirEntry is Readable
=?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
I'm missing a function in std.file that checks if the attributes() member of DirEntry means that the it is readable by a specific user id (defaulted to the current user). Has anybody written such a logic? I know that such a function is not difficult to write (based on the contents of attributes()). But why isn't such a very often used function in the standard library? Note that I've been given the advice in a previous D-post not to rely on file exceptions for checking for file/directory readability.
Sep 22 2013
Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, September 22, 2013 19:46:50 Nordl=C3=B6w wrote:I'm missing a function in std.file that checks if the attributes() member of DirEntry means that the it is readable by a specific user id (defaulted to the current user). Has anybody written such a logic? I know that such a function is not difficult to write (based on the contents of attributes()). But why isn't such a very often used function in the standard library?If you want to know whether a file is readable, then use the file's att= ributes.=20 You can either get them via std.file.getAttributes or DirEntry's attrib= utes=20 property. Then check for whatever bit needs to be set for that specific= system=20 for the attribute that you want. The getAttributes documentation gives = links=20 to where the system-specific attribut stuff can be found: http://dlang.org/phobos/std_file.html#getAttributes For instance, on Linux, for checking user read permissions, you'd do so= mething=20 like import core.sys.posix.sys.stat; import std.file; import std.stdio; auto canRead =3D cast(bool)(getAttributes(filename) & S_IRUSR); auto de =3D DirEntry(filename); auto canRead2 =3D cast(bool)(de.attributes & S_IRUSR); But file permissions are incredibly system-specific, so I don't know if= it makes=20 sense to put them in the standard library or not. For instance, there a= re 3=20 different types of read permissions on Linux but only one on Windows. A= nd you=20 can get weird combinations on Linux like having a file that is not user= - readable but is world-readable, meaning that the user who owns it can s= till=20 read it in spite of the fact that they were not given user read permiss= ions. So, maybe it makes sense to come up with some incredibly generic file=20= permissions for std.file (e.g. readable and writable), ignoring all of = the=20 system-specific permissions involved with that and find a way to sort o= ut all of=20 the permissions quirks for each system to give a generic readable or wr= itable.=20 But the permissions on different file systems are inherently different,= so I=20 don't know how much sense it does or doesn't ultimately make to try and= come=20 up with a generic way to present them.Note that I've been given the advice in a previous D-post not to rely on file exceptions for checking for file/directory readability.The main thing to avoid is doing operations which will throw exceptions= on=20 failure when failure is likely. So, for instance, if you're dealing wit= h a file=20 that may or may not exist, checking whether it exitsts first will avoid= an=20 unnecessary exception. On the other hand, if the file is supposed to be= there,=20 and it's should rarely (if ever) happen that it's not, then you can ski= p the=20 existance check, because the exception is unlikely to occur. In the case of read/write permissions, it's usually the case that the p= rogram=20 has permissions to read or write any files that it's asked to mess with= -=20 especially if you're talking about read permissions. It's quite rare th= at you=20 don't have permissions to read a file. That being the case, in most sit= uations,=20 I don't think that it's worth checking for read/write permissions first= . It=20 really comes down to high likely it is that the operation will fail and= end up=20 throwing an exception. - Jonathan M Davis
Sep 22 2013