$include_dir="/home/hyper-archives/boost-users/include"; include("$include_dir/msg-header.inc") ?>
From: Allen Cronce (allenslists_at_[hidden])
Date: 2008-08-28 21:38:26
In case anyone is interested...
Turns out that my original code intended to detect permissions errors
in a cross platform way did not work on Windows. The comparison has to
be performed on the exception's error_code, not the error_code's
value. The value seems to be platform specific.
So the correct (I think) cross platform solution for detecting a
permissions error is as follows:
if (boost::system::posix_error::permission_denied == e.code())
{
std::cout << "The error code indicates a permissions error, as
expected. " << std::endl;
}
Note the absence of the ".value()" in the comparison.
Best,
--
Allen Cronce
On Aug 10, 2008, at 9:31 AM, Allen Cronce wrote:
> Hi all,
>
> I need to programmatically test for permissions errors during path
> iteration. I think what I need to do is catch the filesystem
> exception, then drill out the error code and compare it to the
> permission_denied error value.
>
> Here's a code fragment written under boost 1.35 that demonstrates
> what I'm talking about:
>
> try
> {
> // Force a permissions error on *nix machines when not running as
> root.
> // Note that this code is is for demonstration purposes only.
> Assume that
> // in the real implementation I'm doing something else here with the
> // filesystem that *might* throw a permissions error.
> boost::filesystem::path testDirPath( "/usr/local/cant_touch_this" );
> create_directory(testDirPath);
> }
> catch(const boost::filesystem::filesystem_error& e)
> {
> // Check the error code to see if it's a permissions error
> if (boost::system::posix_error::permission_denied ==
> e.code().value())
> {
> std::cout << "The error code indicates a permissions error, as
> expected. " << std::endl;
> }
> else
> {
> std::cout << "Hmm... I didn't get a permissions error. That's
> wrong." << std::endl;
> }
> }
>
> Is this basically the right approach?
>
> Note that one concern I have is maintainability. A coworker wrote
> similar code to the above, but under boost 1.33.1. That code broke
> under 1.35 due to significant changes to the filesystem exceptions
> mechanism.
>
> I understand that there are no guarantees moving forward to new
> boost versions. I knew the job was dangerous when I took it ;-) But
> if there's anything I can do today to future-proof a little bit,
> that would be great.
>
> Thanks in advance for any feedback or suggestions.
>
> Best,
> --
> Allen Cronce