smbj
smbj copied to clipboard
Implement java.nio.file.spi.FileSystemProvider
I'd really appreciate the ability to use the java.nio.file api for reading from an SMB share. My usecase is pretty simple (read-only from a static share), and I'm migrating off of a local-filesystem-based solution, so java.nio.file would be way nicer than using smbj's api (as good as it probably is).
(Granted, I'm sure it's not that much to learn... but still)
I've added the enhancement label to this. It's not on the top of the list, but would be nice indeed
Thank you!
Would you be interested in a pull request for this?
It'd be really useful, so I've been hacking around a bit over the holidays - but not sure whether to package as a separate jar or not.
Hi @dgodfrey, definitely, feel free to submit a PR!
Hello! Is there any progress on this? I'm struggling to find a way to efficiently add new files to existing zip archives stored on a remote SMB server. It looks like solving this issue might be a solution. I could then compose this new provider with ZipFileSystemProvider...
@vadipp I've not had time myself, but iof @dgodfrey has something he wants to make a PR for, I'll review it, and we could potentially make this a part of the dist.
Finally made the time to look at this - I've mostly rewritten whatever I wrote a few years ago, it's much better. it's pretty bare-bones atm, as it only supports:
- Files.newBufferedReader / newBufferedWriter
- Files.newInputStream / newOutputStream
- Files.newByteChannel - though I've only tested this via the above 2 points
- Files.newDirectoryStream
- Files.exists
- Files.readAttributes
And even then, the error-handling is lacking, the set-up isn't great and performance could be improved.
See the new integrationTest for examples.
Hopefully this shows the delta: https://github.com/hierynomus/smbj/compare/master...dgodfrey:smbj:feature/fs?expand=1
If not, this is the branch: https://github.com/dgodfrey/smbj/commits/feature/fs
@dgodfrey do you think this could be finalized into a PR an integrated in the lib? I think that would be really helpful and remove the need for custom implementations by using the standard NIO API.
@dgodfrey I tried your impl out and in general it already works, but if one performs a walk in the filetree like this:
Path rootPath = fileSystem.getPath("\\");
Files.walkFileTree(rootPath, new FileVisitor<Path>() {
@Override
public FileVisitResult preVisitDirectory(Path dir, BasicFileAttributes attrs) throws IOException {
System.out.println("Visit directory " + dir);
return FileVisitResult.CONTINUE;
}
@Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
System.out.println("Visit file: " + file);
return FileVisitResult.CONTINUE;
}
@Override
public FileVisitResult visitFileFailed(Path file, IOException exc) throws IOException {
return FileVisitResult.CONTINUE;
}
@Override
public FileVisitResult postVisitDirectory(Path dir, IOException exc) throws IOException {
return FileVisitResult.CONTINUE;
}
});
it results in an infinite loop because it seems to include the '.' (that point to the current dir) and the walk never ends.
I was able to fix this in com.hierynomus.fs.SmbFileSystem.newDirectoryStream(Path, Filter<? super Path>) by skipp the . and .. path.