Comments (7)
@o2themar You're getting that exception because you're calling FileSystems.newFileSystem(URI, Map)
with a URI with the scheme jimfs
. That tells Jimfs to create a new Jimfs file system, not a zip file system, and the URI for a Jimfs file system isn't allowed to have a path, query or fragment (because they don't make sense in that context).
The scheme for a zip file system is jar:<underlying file system scheme>
, so in the case of a file in a Jimfs file system, jar:jimfs
. So your code would probably work if you just pass "jar:" + zipURI.getScheme()
as the scheme for your new URI.
That said, you should be able to get a zip file system for a Jimfs path by just calling FileSystems.newFileSystem(Path, Map)
:
Path zipPath = pathFromJimfs;
Map<String, Object> env = new HashMap<>();
env.put("create", Boolean.toString(Files.notExists(outputZipAbsolutePath)));
env.put("encoding", "UTF-8");
FileSystem zipFileSystem = FileSystems.newFileSystem(zipPath, env);
from jimfs.
Paths.get(URI)
is fine and is the correct way to get a Path
from a URI
... what I was referring to in that issue was Paths.get(String, String...)
, which can only get you a Path
from the default file system.
And JimfsFileSystem
is package-private because users should be able to do everything they need through the normal java.nio.file
APIs without using implementation details of Jimfs itself. It's a bit unfortunate that fs.provider().getPath(uri)
doesn't work; it's a side-effect of something else that had to be done.
from jimfs.
Paths.get(URI)
is doing nothing but finding the file-system provider which matches the URI's scheme and resolving the URI using said provider's getPath(URI)
method. In case the scheme is file
, the method will use the default file system, much like its "sister" Paths.get(String)
; therefore, the same argument could be said for this method as well.
In other words, I'm a user of Jimfs and I would've liked to convert URIs with the file
scheme into a JimfsPath
, the same way I'm able to do with the default file system (which is what I take Jimfs to be an emulator for). fs.provider().getPath(URI)
is exactly the way to do this, and therefore I expect Jimfs to implement it. I would like to know what is the problem with implementing it; perhaps I could help.
from jimfs.
For better or for worse, the design of the whole FileSystem
/ FileSystemProvider
API is such that each FileSystemProvider
must use its own URI scheme. Jimfs URIs start with jimfs:
. From that perspective, a file:
URI means a file on the default file system, period. Also, I'll note that fs.provider().getPath(URI)
is not intended as a way of getting a Path
for one FileSystem
from a URI
that belongs to a different FileSystemProvider
. FileSystemProvider
is an SPI type and generally not intended to be used by user code; FileSystem.provider()
mostly exists because it allows FileSystem
implementations to get at the provider when a Path
is passed to one of their methods.
So, if you have a file:
URI and want to get a Jimfs Path
? First I'd ask where the URI is coming from. If you could, rather than getting a file:
URI in the first place, call toUri()
on a Jimfs Path
to get the URI that you later want to turn into a Jimfs Path
.
Alternatively, you can probably do fs.getPath(uri.getPath())
and it'll just work like you want.
If it doesn't, it might be that constructing a new URI like new URI(anyJimfsPath.getScheme(), anyJimfsPath.getAuthority(), uri.getPath(), null, null)
will work, though I think that should basically be equivalent to the previous suggestion.
from jimfs.
I see your point; the NIO API couples the default provider to the "file" scheme and it's quite hard to undo.
Yeah, fs.getPath(uri.getPath())
is exactly what I used instead (I didn't care for the authority here).
from jimfs.
So I'm having an issue with creating a new URI from a path and I tried using new URI(anyJimfsPath.getScheme(), anyJimfsPath.getAuthority(), uri.getPath(), null, null)
but that didn't work. What I'm trying to do is create a new filesystem for a zip file using a path that was already created using Jimfs.
What I'm doing is this:
Path zipPath = pathFromJimfs;
URI zipURI = zipPath.toUri();
zipURI = new URI(zipURI.getScheme(), zipURI.getAuthority(), zipURI.getPath(), null, null);
Map<String, Object> env = new HashMap<>();
env.put("create", Boolean.toString(Files.notExists(outputZipAbsolutePath)));
env.put("encoding", "UTF-8");
FileSystem zipFileSystem = FileSystems.newFileSystem(zipURI, env);
I'm getting the following exception:
java.lang.IllegalArgumentException: uri (jimfs://11bee858-af79-4dee-aca1-5420ee1c8a00/pathtozip) may not have a path, query or fragment
I debugged the code and yes it does have a path that is not null.
Why isn't this working? I thought as long as the path object is jimfs then I can create a new filesystem using that path object and everything should work as is.
from jimfs.
@cgdecker I got to review this issue again with the recent activity, and I'm appalled at my previous behavior. I apologize for the demanding and combative tone. I really appreciate the work and effort you put into this!
from jimfs.
Related Issues (20)
- Deprecate newFileSystem(...) overloads that default to platform-specific settings HOT 11
- JimfsFileChannel the method read why need synchronized
- JimfsPath.resolve can accept Path instance other than JimfsPath HOT 2
- Check for problems with ByteBuffer covariant return types when building with JDK 9+ HOT 3
- Jimfs release 1.2 HOT 2
- setPermissions and setTimes on symlinks don't behave as on Unix/macOS
- Detect resource leaks
- Allow to write to PathURLConnection HOT 2
- Incorrect block allocation in transferFrom implementation HOT 3
- Sensless feedback loop HOT 1
- FileStore.getBlockSize() should return the configuration block size HOT 1
- How can I create a java RandomAccessFile on the jimfs filesystem? HOT 1
- State of support for JIMFS HOT 4
- Integration of jimfs into OSS-Fuzz HOT 3
- Files.list does not work with jimfs paths (NoSuchFileException) HOT 4
- Files#readAttributes throws NullPointerException for non existent attribute view.
- Drop Java 7 compatibility HOT 2
- Vulnerability reporting inconsistency for CVE-2020-8908 HOT 4
- Files.newOutputStream throws if file is a symlink to a non-existing target. HOT 2
- Jimfs support for JUnit 5 `TempDirFactory` HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jimfs.