smbj icon indicating copy to clipboard operation
smbj copied to clipboard

Implement java.nio.file.spi.FileSystemProvider

Open mattdrees opened this issue 7 years ago • 12 comments
trafficstars

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)

mattdrees avatar Oct 26 '18 16:10 mattdrees

I've added the enhancement label to this. It's not on the top of the list, but would be nice indeed

hierynomus avatar Dec 28 '18 13:12 hierynomus

Thank you!

mattdrees avatar Dec 28 '18 14:12 mattdrees

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.

dgodfrey avatar Jan 10 '19 01:01 dgodfrey

Hi @dgodfrey, definitely, feel free to submit a PR!

hierynomus avatar Jan 10 '19 09:01 hierynomus

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 avatar Feb 18 '22 09:02 vadipp

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

hierynomus avatar Feb 18 '22 10:02 hierynomus

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 avatar Sep 28 '22 10:09 dgodfrey

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

laeubi avatar Apr 21 '23 07:04 laeubi

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

laeubi avatar Apr 23 '23 11:04 laeubi