Skip to content
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

Files.newOutputStream throws if file is a symlink to a non-existing target. #254

Open
oldergod opened this issue Jun 21, 2023 · 2 comments
Labels
P3 type=defect Bug, not working as expected

Comments

@oldergod
Copy link

oldergod commented Jun 21, 2023

For simplicity, here is what I do in bash:

$ ls symlink-target
> ls: symlink-target: No such file or directory
$ ln -s symlink-target symlink-source
$ echo hello > symlink-source
$ cat symlink-target
> hello

Jimfs would throw the following (version: 1.2)

java.nio.file.FileSystemException: symlink-source: not a regular file
	at com.google.common.jimfs.FileSystemView.getOrCreateRegularFileWithWriteLock(FileSystemView.java:336)
	at com.google.common.jimfs.FileSystemView.getOrCreateRegularFile(FileSystemView.java:298)
	at com.google.common.jimfs.JimfsFileSystemProvider.newOutputStream(JimfsFileSystemProvider.java:201)
	at java.base/java.nio.file.Files.newOutputStream(Files.java:228)

The code would work fine if I were to use Filesystems.getDefault(), and as show at the top, this would also work in the CLI.

@cpovirk
Copy link
Member

cpovirk commented Jun 21, 2023

Thanks. I traced down to here:

if (file.isSymbolicLink()) {
DirectoryEntry linkResult = followSymbolicLink(dir, (SymbolicLink) file, linkDepth);
if (linkResult == null) {
return null;
}

I wonder if we'll need to plumb some kind of custom LinkOption-like "return a link target even if it does not exist" flag through the whole lookUp family of methods so that we can return a non-null DirectoryEntry in this case? And then lookUpRegularFile would have to create in that case? Or maybe we should call readSymbolicLink up front (I guess while holding the lock) and work from there?

It's interesting behavior.... This is something that @cgdecker will have a more knowledgeable perspective on when he's back from vacation.

@cpovirk cpovirk added type=defect Bug, not working as expected P3 labels Jun 21, 2023
@cgdecker
Copy link
Member

Hmm... it does seem like we'd need to be able to represent a non-existent file as a DirectoryEntry and then change some operations that look for a null DE. I wouldn't be surprised if it would be possible to simplify some other things by doing that as well, like for example Files.newOutputStream for a non-existent file, but I haven't looked into it too deeply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 type=defect Bug, not working as expected
Projects
None yet
Development

No branches or pull requests

3 participants