-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for relative paths or documentation of differences to Path behaviour #89
Comments
You are probably right that File.nameWithoutExtension should not do I/O but I disagree that this library should strive to mimic nio.Path in general. |
To be clear: I'm not saying better-files should mimic nio.Path, but in the absence of docs that state how better-files behaves, or differs from nio.Path, it seems a natural assumption. So maybe add a note to the Instantiation section to state that all paths are normalized to absolute paths during instantiation? |
@jotomo : Yes, plan to strongly-type the paths anyway (see #88 (comment)) But, I have a separate question for the I think we need to distinguish between a "vitrual file" vs. "a real file that exists on the file system". |
The more I think about this, the trickier the separation between just manipulating a File instance vs. doing I/O gets. isDirectory needs to do I/O, so hasExtension should be allowed to do I/O as well when required (I'm aware I'm arguing against my initial statement). |
In that case, the current behavior is correct: def hasExtension: Boolean =
(isRegularFile || notExists) && (name contains ".") The above will return true if name has a |
Agreed. I think my original irritation was misunderstanding the behaviour of nio.Files.notExists (and neighbouring methods), or rather not thinking about the underlying Java code, which swallows exceptions and returns false when "the state of the file can't be determined". The effect, when working with a file one isn't allowed to access has these results then: File("/root/test.txt").hasExtension => false
File("/root/test.txt").nameWithoutExtension => "test.txt"
Files.isRegularFile(Paths.get("/root/test.txt")) => false
Files.isDirectory(Paths.get("/root/test.txt")) => false
Files.notExists(Paths.get("/root/test.txt")) => false
Files.exists(Paths.get("/root/test.txt")) => false
Files.isReadable(Paths.get("/root/test.txt")) => false I don't have an answer as to what the behaviour should be. I think though that I need to make my code more resilient and maybe start with isReadable when there's a chance a permission problem might exist. Hm, hasExtension could start with an isReadable maybe, not sure though if this is the right place to address those issues. |
Well atleast these 2 are consistent: File("/root/test.txt").hasExtension => false
File("/root/test.txt").nameWithoutExtension => "test.txt" I think the resolution for this is to document the fact that for unreadable files, we assume it is not a "regular file" and thus has no extension. |
👍 Agreed. Thanks for condensing my ponderings into something actionable :-) |
I'm in the process of moving from Java NIO to this library. File's Javadoc state it's a wrapper around java.nio.Path, so I was expecting the same semantics. However, File does not support relative paths, but converts everything to absolute paths during instantiation. This leaves me puzzled ...
If this behaviour is by design, I think it should be documented.
P.S. Why does File.nameWithoutExtension does I/O, checking a file is either a regular file or not existing? This was also surprising when transferring assumptions over from the behaviour of Path and caused a subtle bug in my test: the file in question was in a directory to which the user had no access, so File.hasExtension returned false, so that File.nameWithoutExtension simply returned the name with the extension.
The text was updated successfully, but these errors were encountered: