Kotlin / kotlinx-io

Kotlin multiplatform I/O library
Apache License 2.0
1.3k stars 59 forks source link

Add permissions to FileMetadata #232

Open StefanOltmann opened 1 year ago

StefanOltmann commented 1 year ago

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.

fzhinkin commented 9 months ago

@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.

StefanOltmann commented 9 months ago

@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.

fzhinkin commented 9 months ago

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.

StefanOltmann commented 9 months ago

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 commented 4 months ago

@fzhinkin Any new thoughts on this?

qwwdfsad commented 4 months ago

@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