kotlinx-io icon indicating copy to clipboard operation
kotlinx-io copied to clipboard

Add permissions to FileMetadata

Open StefanOltmann opened this issue 2 years ago • 6 comments
trafficstars

I require an equivalent for java.io.File.canRead() and java.io.File.canWrite() to determine whether it's possible to read from or write to a file. This information is important in the case of Ashampoo Photos to decide whether to directly write metadata to an image file or use a sidecar file.

StefanOltmann avatar Nov 06 '23 11:11 StefanOltmann

@StefanOltmann, it's just a better alternative to opening a file and catching IOException thrown due to missing permission, right? Not arguing about the necessity of an API, just trying to figure out a particular use case.

fzhinkin avatar Feb 23 '24 17:02 fzhinkin

@fzhinkin Exception handling is always painfully slow. So using Exceptions as part of the workflow code (for example catching NumberParseException so test if some string contains a number) is considered an anti pattern.

The file system already has the information about the file permissions and can be accessed in a fast way.

I described a use case for that in my first post. I want to directly write a sidecar for read-only files without catching an exception first. Exceptions slow down the process by a lot.

StefanOltmann avatar Feb 23 '24 17:02 StefanOltmann

The problem with such a test is that a file may change its permissions in between getPermissions/getMetadata call and openFile call, so having good permissions initially does not guarantee a successful opening (which may still throw an exception).

Speaking of performance, I'm not sure that catching an exception will be slower than a call fetching file metadata (as the latter requires a native call that, in turn, makes a system call). But as an alternative, open may return null on failure instead of throwing an exception.

fzhinkin avatar Feb 23 '24 22:02 fzhinkin

At least java.io.File.canRead() is faster than handling the exception.

A permission change between the check and openFile will be rare (as there are only milliseconds in between), but if it happened and the file is not readable throwing an exception is correct behavior. I think it’s a better than returning null.

I don’t seek to avoid exceptions at all costs, I’m just against using them in the regular workflow as Exception handling in Java is painfully slow.

StefanOltmann avatar Feb 24 '24 07:02 StefanOltmann

@fzhinkin Any new thoughts on this?

StefanOltmann avatar Jul 16 '24 12:07 StefanOltmann

@fzhinkin is currently unavailable.

Filesystem support (which includes extending metadata beyond what we are providing currently) is part of our stabilization roadmap, and high chance this request will be incorporated into the support provided

qwwdfsad avatar Jul 16 '24 12:07 qwwdfsad