Added try/catch block for possible exception from boost::filesystem::…

[indianajohn]

…permissions.

On filesystems in which the current unix user does not have permissions to change permissions on a target file, boost::filesystem::permissions will throw

std::runtime_error("boost::filesystem::permissions: Operation not permitted: \"/path/to/file\"")

Specifically, calls to

pcl::io::savePCDFile(...);

result in an std::runtime_error being thrown and SIG_ABORT being called. Naturally, it is possible to catch this error upstream with

try 
{
  pcl::io::savePCDFile(...);
}
catch (const std::runtime_error &e)
{
  // Do something
}

However, doing the above results in no file being written.

This situation arose for me when I was trying to use PCL on Android with Boost 1.58. Presumably files created on the SD card are not owned by the user executing the process, so changing ownership is forbidden. Unfortunately, a minimal example of this situation would not be very minimal; you would have to cross-compile PCL for Android, make an NDK project, and try the above code. I assume you have your own methods of doing the above, but I would be happy to discuss more details if necessary.

The code in the pull request simply warns the user if permissions were not able to be set/reset on the file. In my specific case, using the patch provided by this pull request, a call to writePCDFile(...) resulted in a successful write. This seems to be better than the outcome when either of the above examples are run: either a SIG_ABORT or nothing happening at all. It also seems to mesh with the logic of the surrounding code; evidenced by the "#ifndef WIN32" block surrounding the contents of the function, the method is not critical to execution, and the failure of it to be executed on *nix would just mirror the behavior of what is already happening on WIN32.

Let me know if you need more information, or if you would prefer another approach.

Best Regards,
John

[VictorLamoine]

I also encountered this problem when trying to write on a FAT32 partition (which does not support permissions) on a Linux distribution.
So a FAT32 partition should be easier as an example!

[taketwo]

Locking was introduced in 170cb92. I think the description supports your hypothesis that it is optional. Therefore 👍 to this patch.