From Guava 32.0.1-jre, Files.createTempDir() and FileBackedOutputStream can fail or create un-deletable directories/files when used from a Windows service #6634

fmarot · 2023-07-12T13:35:30Z

Hello I rencently upgraded from 31.1-jre to 32.0.1-jre.
FYI 32.0.0-jre was KO because of the then-corrected-in-32.0.1-jre error: java.lang.UnsupportedOperationException: 'posix:permissions' not supported as initial attribute. So let's not talk about this version.

In 32.0.1-jre the method Files.createTempDir() has been modified and a program RUNNING ON WINDOWS is now unable to delete its own folders created by this call.

Here is a sample creating a folder with java's own "createTempDirectory" and deleting it (this works fine) and then the same with Guava and it cannot delete it's own folder created with guava.


        @Test
	public void testApp() throws IOException {
		Path tempDir = java.nio.file.Files.createTempDirectory("temp");
		displayDirectoryPermissions(tempDir);
		boolean isDeleted = tempDir.toFile().delete();
		assertTrue(isDeleted);

		System.out.println(" - - - - - - - - - ");

		Path tempDir2 = Files.createTempDir().toPath();
		displayDirectoryPermissions(tempDir2);
		boolean isDeleted2 = tempDir2.toFile().delete();
		assertTrue(isDeleted2);
	}

	private static void displayDirectoryPermissions(Path directory) throws IOException {
        System.out.println("Informations sur les droits d'accès du répertoire : " + directory.toAbsolutePath());

		AclFileAttributeView view = java.nio.file.Files.getFileAttributeView(directory, AclFileAttributeView.class);
		System.out.println(view.toString());

		view.getAcl().forEach(it -> System.out.println(it.toString()));
    }

Here are the (desidentified) trace and there is a huge difference beween both calls:

Informations sur les droits d'accès du répertoire : e:\xxxxxxx\target\temp18063228888024228555
sun.nio.fs.WindowsAclFileAttributeView@7494f96a
BUILTIN\Administrators:READ_DATA/WRITE_DATA/APPEND_DATA/READ_NAMED_ATTRS/WRITE_NAMED_ATTRS/EXECUTE/DELETE_CHILD/READ_ATTRIBUTES/WRITE_ATTRIBUTES/DELETE/READ_ACL/WRITE_ACL/WRITE_OWNER/SYNCHRONIZE:ALLOW
BUILTIN\Administrators:FILE_INHERIT/DIRECTORY_INHERIT/INHERIT_ONLY:ALLOW
NT AUTHORITY\SYSTEM:READ_DATA/WRITE_DATA/APPEND_DATA/READ_NAMED_ATTRS/WRITE_NAMED_ATTRS/EXECUTE/DELETE_CHILD/READ_ATTRIBUTES/WRITE_ATTRIBUTES/DELETE/READ_ACL/WRITE_ACL/WRITE_OWNER/SYNCHRONIZE:ALLOW
NT AUTHORITY\SYSTEM:FILE_INHERIT/DIRECTORY_INHERIT/INHERIT_ONLY:ALLOW
NT AUTHORITY\Authenticated Users:READ_DATA/WRITE_DATA/APPEND_DATA/READ_NAMED_ATTRS/WRITE_NAMED_ATTRS/EXECUTE/READ_ATTRIBUTES/WRITE_ATTRIBUTES/DELETE/READ_ACL/SYNCHRONIZE:ALLOW
NT AUTHORITY\Authenticated Users:DELETE:FILE_INHERIT/DIRECTORY_INHERIT/INHERIT_ONLY:ALLOW
BUILTIN\Users:READ_DATA/READ_NAMED_ATTRS/EXECUTE/READ_ATTRIBUTES/READ_ACL/SYNCHRONIZE:ALLOW
BUILTIN\Users:FILE_INHERIT/DIRECTORY_INHERIT/INHERIT_ONLY:ALLOW
 - - - - - - - - - 
Informations sur les droits d'accès du répertoire : e:\xxxxxxx\target\3980498532511240827
sun.nio.fs.WindowsAclFileAttributeView@32502377
WINDOWS-DOMAIN\computerName$:READ_DATA/WRITE_DATA/APPEND_DATA/READ_NAMED_ATTRS/WRITE_NAMED_ATTRS/EXECUTE/DELETE_CHILD/READ_ATTRIBUTES/WRITE_ATTRIBUTES/DELETE/READ_ACL/WRITE_ACL/WRITE_OWNER/SYNCHRONIZE:FILE_INHERIT/DIRECTORY_INHERIT:ALLOW

The text was updated successfully, but these errors were encountered:

cpovirk · 2023-07-12T14:14:55Z

Thanks for all the details.

At first glance, I'm puzzled: We test that we can delete the directory, and we have had our tests running under Windows. We have also tested manually under Windows, as have other users, and we've heard of apps that started working again at 32.0.1. So there must be some variation between systems that accounts for this.

One thing that I'd wondered was whether the system property user.name is the right one to use. Maybe it's not? It looks like the code ended up granting permissions to a user "computerName$" (if I'm understanding right). Maybe that's not actually the user that we need? (I do think I found that Java would fail if we tried to set a user that does not exist, at least in the testing I did.) It's interesting that the java.nio.file.Files.createTempDirectory() output doesn't appear to mention a specific user at all (again, if I'm understanding right). I think I'd seen a specific user listed in my testing.

One frustrating part of this is that we might not need to set explicit permissions at all: The Windows temporary directory is very likely to be secure, and the Java's Linux implementation appears to set restricted permissions by default (but its docs are coy about this). Maybe I should just rip out all the permissions code. I've been hesitant to do so because it would look quite bad if such a change somehow reintroduced the security bug. (And of course now we've already had a bunch of releases in quick succession....)

Does anything about the username issue give you any ideas? Does anyone else have thoughts?

cpovirk · 2023-07-12T14:21:16Z

"Computername$ implies that it is coming from something running as local system. Local admins can also do this."

Does that sound like the situation you're in?

Hmm, and regardless, could you have a look at the "e:\xxxxxxx\target" directory and see if it's world-readable? If it's world-readable, then that shows that we do need to set directory permissions for maximum security in this case. If it's not, then that's another data point in favor of the idea that the Windows temporary directory is always secure.

fmarot · 2023-07-13T07:55:53Z

Hello cpovirk,

I'm sorry I should really have mentionned a few things first in my report:
1- I'm running a Jenkins worker as a Windows Service with default rights so it runs as "local system" (see the bottom of the screenshot)
2- I explicitly set the Java temp directory to -Djava.io.tmpdir=e:\xxxxxxx/target (the classic Maven build directlry) so I do not bother having to clean temporary files left in the temp dir as it is handled by a "mvn clean"

I added this code in the program to obtain the username:

com.sun.security.auth.module.NTSystem NTSystem = new com.sun.security.auth.module.NTSystem();
System.out.println("NTSystem.getName(): " + NTSystem.getName());

System.out.println("System.getProperty(user.name): " + System.getProperty("user.name")); //platform independent

and it leads to this output:

NTSystem.getName(): SYSTEM
System.getProperty(user.name): COMPUTERNAME$

(yes, COMPUTERNAME is uppercase here where it is lowercase in the ACL list)

Here are the info regarding the 'target' directory rights: it seems world-readable:

cpovirk · 2023-07-13T12:46:40Z

Wow, I don't even remember hearing about the javax.security.auth classes before. I wonder if there's a way to get at the value of NTSystem.getName() through non-internal APIs. Alternatively, maybe Guava should automatically map a user.name of COMPUTERNAME$ to SYSTEM and see what happens....

At this point, I would love to get away with keeping things as they are. And we might get away with it if you're in a position to migrate off our method and onto java.nio.file.Files.createTempDirectory. But since you mentioned Jenkins, I assume that it's Jenkins that contains the call and thus Jenkins that would have to perform the migration? (Or rather, JENKINS-71375 suggests that the change needs to happen in JFrog, a dependency of Jenkins....)

Aside from my idea of mapping COMPUTERNAME$ to SYSTEM, I could also see making Guava read a system property (or maybe environment variable, which feels marginally safer, since Java doesn't let programs mutate environment variables) that lets you disable setting the ACL. Would you be in a position to set the system property or environment variable?

And, similarly, for the idea of rewriting user.name: Are you able to test running your Java app with -Duser.name=SYSTEM and seeing if that helps? (Hopefully it's not too hard to set that option on the correct VM: I don't know how many different Java processes are involved when you're running Jenkins. Maybe the easier approach would be to call System.setProperty("user.name", "SYSTEM"); sometime before using Files.createTempDir (and before using FileBackedOutputStream, but you probably don't use that in the first place).

cgdecker · 2023-07-13T17:49:54Z

I'm sure there's context I'm not remembering, but just to double-check: did we determine that it is in fact necessary to explicitly set the ACL when creating temp dirs on Windows, as opposed to passing no FileAttributes at all and letting Windows do its default thing?

fmarot · 2023-07-13T20:51:20Z

Hello,
a few comments & answer below:

to cgdecker: I'm not in Guava team but I know that the default windows temp dir is user-specific. So from my (limited) point of view, there is not really a need to set anything specific. In my case I explicitly tell Java to use another dir (through -Djava.io.tmpdir=e:\xxxxxxx\target ) so responsibility for setting limited rights could be on my side. I would find it fair.

to cpovirk 1-: please do not modify anything for me. I already simply moved my tests away from using Guava's createTempDir() to java.nio.file.Files.createTempDirectory(). That was an easy move. Ijust reported the bug so that you know there is a problem others may face. It's not a blocker anymore for me.

to cpovirk 2-: you were right, launching my tests with -Duser.name=SYSTEM corrected the problem. The process was able to correctly delete it's own temporary dir.

for the record, the problem mentioned in JENKINS-71375 is specific to version 32.0.0-jre and was corrected in 32.0.1-jre and I think that only daemon services (and maybe especially the ones changing the default temp dir like I did) will be hurt with the same bug as described here.

cpovirk · 2023-07-14T17:21:45Z

Thanks for the additional details and testing.

It does seem extremely likely that plain java.nio.file.Files.createTempDirectory is secure. But the Linux-related JDK docs are noncommittal, saying something like like "the file/directory created might have more restricted permissions than you asked for." That sounds like it might be referring to the umask, but I was seeing even more restricted permissions than the umask asked for (which is good from the security perspective). Perhaps because of the ambiguity, some docs suggest setting the permissions explicitly. And then Windows is its own story, with the temporary directory itself normally secure, as you said. Here's some previous discussion.

I'm going to re-title this bug to reflect that it applies just to the daemon case. If we end up hearing from more affected users, we can reevaluate. Thanks for your flexibility.

Uli-Tiger · 2023-09-26T16:58:44Z

@cpovirk
We run into a similar issue. Root cause is the same, but we can not even create a temp dir.
We have here a Jenkins based CI running on windows. The jobs are executed by Jenkins nodes which are installed as windows services, hence running as windows SYSTEM account, which is the default service user under windows.
Some test code calls Files.createTempDir(), which internally resolves system property user.name to PIPELINE$ (PIPELINE is the computer name) instead of SYSTEM. Hence creating of temp dir fails, as there is no user named PIPELINE$.
we see then the following exception

java.lang.IllegalStateException: Failed to create directory
	at com.google.common.io.TempFileCreator$JavaNioCreator.createTempDir(TempFileCreator.java:110)
	at com.google.common.io.Files.createTempDir(Files.java:438)
	[...]
Caused by: java.io.IOException: Could not find user
	at com.google.common.io.TempFileCreator$JavaNioCreator.lambda$userPermissions$4(TempFileCreator.java:178)
	at com.google.common.io.TempFileCreator$JavaNioCreator.createTempDir(TempFileCreator.java:107)
Caused by: java.nio.file.attribute.UserPrincipalNotFoundException
	at java.base/sun.nio.fs.WindowsUserPrincipals.lookup(WindowsUserPrincipals.java:148)
	at java.base/sun.nio.fs.WindowsFileSystem$LookupService$1.lookupPrincipalByName(WindowsFileSystem.java:247)
	at com.google.common.io.TempFileCreator$JavaNioCreator.userPermissions(TempFileCreator.java:153)
	at com.google.common.io.TempFileCreator$JavaNioCreator.<clinit>(TempFileCreator.java:138)
	at com.google.common.io.TempFileCreator.pickSecureCreator(TempFileCreator.java:65)
	at com.google.common.io.TempFileCreator.<clinit>(TempFileCreator.java:51)

windows version

Edition	Windows Server 2022 Standard
Version	21H2
Installed on	‎7/‎18/‎2022
OS build	20348.169

trying to workarround by setting user.name to SYSTEM as java argument when invoking test command

rishiraj88 · 2023-09-26T17:38:46Z

Across various OSs, there are different environment variable names for username. For example, USERNAME in Windows and USER in Linux.

cpovirk · 2023-09-26T17:46:25Z

Thanks. USERNAME is a possibility.

Are any of the Windows Services users in a position to see what ProcessHandle.current().info().user().get() returns? That might be the true answer.

cpovirk · 2023-09-26T18:08:04Z

I'm going to implement that approach now, since the Stack Overflow question sounds like just the same situation.

…_services_, a rare use case. Fixes #6634 Relevant to #2686 in that it shows that we would ideally run our Windows testing under both Java 8 *and* a newer version.... RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under [Windows _services_, a rare use case](#6634). PiperOrigin-RevId: 568604081

Fix `Files.createTempDir` and `FileBackedOutputStream` under Windows _services_, a rare use case. Fixes #6634 Relevant to #2686 in that it shows that we would ideally run our Windows testing under both Java 8 *and* a newer version.... RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under [Windows _services_, a rare use case](#6634). PiperOrigin-RevId: 568604081

…ting Fix `Files.createTempDir` and `FileBackedOutputStream` under Windows _services_, a rare use case. Fixes #6634 Relevant to #2686 in that it shows that we would ideally run our Windows testing under both Java 8 *and* a newer version.... RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under [Windows _services_, a rare use case](#6634). PiperOrigin-RevId: 568604081

…_services_, a rare use case. Fixes #6634 Relevant to #2686 in that it shows that we would ideally run our Windows testing under both Java 8 *and* a newer version.... RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under [Windows _services_, a rare use case](#6634). PiperOrigin-RevId: 568604081

cpovirk · 2023-09-27T00:52:02Z

@fmarot @Uli-Tiger

Which version of Java are those of you who are affected using? The fix I've been working on would work for Java 9+. If you need support for Java 8, then I would need to add another fix specific to that case.

fmarot · 2023-09-27T07:30:59Z

thanks @cpovirk , I'm using Java11

Uli-Tiger · 2023-09-27T07:54:50Z

thanks @cpovirk , we are using java 17 LTS

cpovirk · 2023-09-27T14:40:44Z

Thanks, I'll stick with the Java 9+ solution for now, then.

Also, I've retitled this bug to reflect that even creating the directories can fail.

If all goes well, I'll submit the fix this week. Then it's just a question of how soon we do a release. How did the workaround of setting user.name go?

cpovirk · 2023-09-27T15:12:52Z

Aside: Somehow my Google search for "ProcessHandle.current().info().user().get()" turns up only one web page. Luckily, my earlier, different search had turned up the Stack Overflow answer with that content anyway... somehow. This was almost as bad as finding a web page that explains how to set an ACL in the first place :)

fmarot · 2023-09-28T12:58:02Z

Copy pasting from a previous message above, it seems the user.name workaround worked well in my tests at the time ;)

: you were right, launching my tests with -Duser.name=SYSTEM corrected the problem. The process was able to correctly delete it's own temporary dir.

cpovirk · 2023-09-28T13:04:39Z

Oops, sorry, I'd seen that but had wanted to check with @Uli-Tiger, since this new problem was slightly different. But I do still expect your workaround to address it.

Uli-Tiger · 2023-09-29T09:43:19Z

Thanks, I'll stick with the Java 9+ solution for now, then.

Also, I've retitled this bug to reflect that even creating the directories can fail.

If all goes well, I'll submit the fix this week. Then it's just a question of how soon we do a release. How did the workaround of setting user.name go?

Because the java process is launched from another process, i couldn't easily inject that system property. Instead i just let the Jenkins service run with an ordinary Admin User instead of the local service account. That works now fine.

I've found them to be [flaky](#6731 (comment)). We already [skip](#2130) some tests under Windows, so what's two more (especially only under Java 8, which I didn't include when setting up [Windows CI](#2686) and which I was testing only as part of #6634)? RELNOTES=n/a PiperOrigin-RevId: 568645480

I've found them to be [flaky](#6731 (comment)). We already [skip](#2130) some tests under Windows, so what's two more (especially only under Java 8, which I didn't include when setting up [Windows CI](#2686) and which I was testing only as part of #6634)? RELNOTES=n/a PiperOrigin-RevId: 570103461

…_services_ (at least under JDK 9+), a rare use case. Fixes #6634 Relevant to #2686 in that it shows that we would ideally run our Windows testing under both Java 8 *and* a newer version.... RELNOTES=`io`: Fixed `Files.createTempDir` and `FileBackedOutputStream` under [Windows _services_, a rare use case](#6634). (The fix actually covers only Java 9+ because Java 8 would require an additional approach. Let us know if you need support under Java 8.) PiperOrigin-RevId: 568604081

``` Building and deploying the android flavor (this may take a while)... [ERROR] We have duplicated artifacts attached. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-source-plugin:3.3.0:jar (attach-sources) on project guava: Presumably you have configured maven-source-plugn to execute twice times in your build. You have to configure a classifier for at least on of them. -> [Help 1] ``` I had fixed the same issue with _snapshot_ deployment in cl/559489724 (by no longer passing `source:jar` to `mvn`), but apparently that fix doesn't apply to _release_ deployment. I'm guessing that the relevant part of our release command is `-Psonatype-oss-release`, which (among other things) [activates a `maven-source-plugin` configuration change](https://github.com/google/guava/blob/a78bea41aedba50469641968ee3d98b24836e491/pom.xml#L329-L334): Presumably that introduces a second `maven-source-plugn` execution in much the same way as passing `source:jar` does. I previously fixed a similar problem in jimfs (cl/536746714) by removing the "normal" `maven-source-plugin` configuration, leaving only the `sonatype-oss-release` configuration in the parent. (I don't remember whether I investigated removing the `sonatype-oss-release` configuration instead. Probably I should have at least investigated.) So I'm doing the same for Guava in this CL. Hopefully this won't interfere with _snapshot_ source jars, which currently are produced even without `source:jar` but might no longer be. If it does cause problems, then I should _definitely_ investigate removing the `sonatype-oss-release` configuration instead. (Encouragingly, [jimfs snapshots](https://oss.sonatype.org/content/repositories/snapshots/com/google/jimfs/jimfs/HEAD-SNAPSHOT/) appear to be fine... _but_ jimfs [still passes `source:jar`](https://github.com/google/jimfs/blob/acb81e8718adf2527be105c6c9b130ec788c9877/.github/workflows/ci.yml#L81).... So I do somewhat expect this to blow up—but, on the bright side, to also teach me something, at which point maybe we can get the config right for both these projects and others to come.) (I went to check whether `guava-*-source.jar` was still being generated in my test release. But somehow I see _no_ jars under `guava/target`, even as I see all(?) the expected ones under `guava-testlib`, etc. I wonder if the release script did a little housekeeping? Sigh, this is really going to blow up, isn't it?) (Notice that the configuration that may be the source of the problem was copied from the old `oss-parent` pom. This is at least the second time that that pom's configuration has caused us trouble, the other I recall being cl/492304151—well, and probably the aforementioned jimfs source-jar issue, too.) This prepares for the release that contains the fix for #6634, among other issues. RELNOTES=n/a PiperOrigin-RevId: 571437790

``` Building and deploying the android flavor (this may take a while)... [ERROR] We have duplicated artifacts attached. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-source-plugin:3.3.0:jar (attach-sources) on project guava: Presumably you have configured maven-source-plugn to execute twice times in your build. You have to configure a classifier for at least on of them. -> [Help 1] ``` I had fixed the same issue with _snapshot_ deployment in cl/559489724 (by no longer passing `source:jar` to `mvn`), but apparently that fix doesn't apply to _release_ deployment. I'm guessing that the relevant part of our release command is `-Psonatype-oss-release`, which (among other things) [activates a `maven-source-plugin` configuration change](https://github.com/google/guava/blob/a78bea41aedba50469641968ee3d98b24836e491/pom.xml#L329-L334): Presumably that introduces a second `maven-source-plugn` execution in much the same way as passing `source:jar` does. I previously fixed a similar problem in jimfs (cl/536746714) by removing the "normal" `maven-source-plugin` configuration, leaving only the `sonatype-oss-release` configuration in the parent. I don't remember whether I investigated removing jimfs' `sonatype-oss-release` configuration instead. Probably I should have at least investigated, since that's what we're going with here. As best I can tell, this doesn't interfere with _snapshot_ source jars, which are produced even without `source:jar`. (Notice that the configuration that may be the source of the problem was copied from the old `oss-parent` pom. This is at least the second time that that pom's configuration has caused us trouble, the other I recall being cl/492304151—well, and probably the aforementioned jimfs source-jar issue, too.) This prepares for the release that contains the fix for #6634, among other issues. RELNOTES=n/a PiperOrigin-RevId: 571437790

``` Building and deploying the android flavor (this may take a while)... [ERROR] We have duplicated artifacts attached. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-source-plugin:3.3.0:jar (attach-sources) on project guava: Presumably you have configured maven-source-plugn to execute twice times in your build. You have to configure a classifier for at least on of them. -> [Help 1] ``` I had fixed the same issue with _snapshot_ deployment in cl/559489724 (by no longer passing `source:jar` to `mvn`), but apparently that fix doesn't apply to _release_ deployment. I'm guessing that the relevant part of our release command is `-Psonatype-oss-release`, which (among other things) [activates a `maven-source-plugin` configuration change](https://github.com/google/guava/blob/a78bea41aedba50469641968ee3d98b24836e491/pom.xml#L329-L334): Presumably that introduces a second `maven-source-plugn` execution in much the same way as passing `source:jar` does. I previously fixed a similar problem in jimfs (cl/536746714) by removing the "normal" `maven-source-plugin` configuration, leaving only the `sonatype-oss-release` configuration in the parent. I don't remember whether I investigated removing jimfs' `sonatype-oss-release` configuration instead. Probably I should have at least investigated, since that's what we're going with here. As best I can tell, this doesn't interfere with _snapshot_ source jars, which are produced even without `source:jar`. (Notice that the configuration that may be the source of the problem was copied from the old `oss-parent` pom. This is at least the second time that that pom's configuration has caused us trouble, the other I recall being cl/492304151—well, and probably the aforementioned jimfs source-jar issue, too.) This prepares for the release that contains the fix for #6634, among other issues. RELNOTES=n/a PiperOrigin-RevId: 572327204

cpovirk · 2023-10-18T00:15:29Z

For anyone who's following here but not following our repo as a whole: The fix for this is part of last week's https://github.com/google/guava/releases/tag/v32.1.3. If you see any problems with that version, please let us know.

eamonnmcmanus assigned cpovirk Jul 12, 2023

eamonnmcmanus added type=defect Bug, not working as expected status=triaged P2 labels Jul 12, 2023

kluever added the package=io label Jul 12, 2023

cpovirk mentioned this issue Jul 13, 2023

Fails on Windows with Guava 32.0.0 jfrog/build-info#737

Open

cpovirk changed the title ~~Guava 32.0.1-jre breaks Files.createTempDir() on Windows with un-deletable directories~~ From Guava 32.0.1-jre, Files.createTempDir() creates un-deletable directories when used from a Windows service Jul 14, 2023

cpovirk added P4 and removed P2 labels Jul 14, 2023

cpovirk mentioned this issue Sep 26, 2023

Require Java 11+ to *build* Guava but continue to support Java 8 at runtime #6549

Open

cpovirk added P2 and removed P4 labels Sep 26, 2023

copybara-service bot mentioned this issue Sep 26, 2023

Fix Files.createTempDir and FileBackedOutputStream under Windows _services_ (at least under JDK 9+), a rare use case. #6730

Closed

cpovirk mentioned this issue Sep 26, 2023

clone of https://github.com/google/guava/pull/6730 but with Windows testing on JDK8 #6731

Closed

cpovirk mentioned this issue Sep 26, 2023

clone of https://github.com/google/guava/pull/6730 but without the prod change -- should fail Windows testing #6732

Closed

cpovirk changed the title ~~From Guava 32.0.1-jre, Files.createTempDir() creates un-deletable directories when used from a Windows service~~ From Guava 32.0.1-jre, Files.createTempDir() can fail or create un-deletable directories when used from a Windows service Sep 27, 2023

cpovirk mentioned this issue Sep 29, 2023

Files#createTempDir stopped working on Windows with 32.0.0 #6535

Closed

copybara-service bot mentioned this issue Oct 2, 2023

Skip a couple ServiceManager tests when running Java 8 on Windows. #6738

Closed

cpovirk mentioned this issue Oct 6, 2023

FileBackedOutputStream failing to write with system account on windows #6750

Closed

copybara-service bot closed this as completed in f87f68c Oct 6, 2023

cpovirk added this to the 32.1.3 milestone Oct 6, 2023

copybara-service bot mentioned this issue Oct 6, 2023

Fix double-source-jar error during releases: #6755

Merged

yahavi mentioned this issue May 17, 2024

Update Guava and commons-compress jfrog/build-info#789

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

From Guava 32.0.1-jre, Files.createTempDir() and FileBackedOutputStream can fail or create un-deletable directories/files when used from a Windows service #6634

From Guava 32.0.1-jre, Files.createTempDir() and FileBackedOutputStream can fail or create un-deletable directories/files when used from a Windows service #6634

fmarot commented Jul 12, 2023

cpovirk commented Jul 12, 2023

cpovirk commented Jul 12, 2023

fmarot commented Jul 13, 2023 •

edited

cpovirk commented Jul 13, 2023

cgdecker commented Jul 13, 2023

fmarot commented Jul 13, 2023

cpovirk commented Jul 14, 2023

Uli-Tiger commented Sep 26, 2023 •

edited

rishiraj88 commented Sep 26, 2023

cpovirk commented Sep 26, 2023

cpovirk commented Sep 26, 2023

cpovirk commented Sep 27, 2023

fmarot commented Sep 27, 2023

Uli-Tiger commented Sep 27, 2023

cpovirk commented Sep 27, 2023

cpovirk commented Sep 27, 2023

fmarot commented Sep 28, 2023

cpovirk commented Sep 28, 2023

Uli-Tiger commented Sep 29, 2023 •

edited

cpovirk commented Oct 18, 2023

From Guava 32.0.1-jre, Files.createTempDir() and FileBackedOutputStream can fail or create un-deletable directories/files when used from a Windows service #6634

From Guava 32.0.1-jre, Files.createTempDir() and FileBackedOutputStream can fail or create un-deletable directories/files when used from a Windows service #6634

Comments

fmarot commented Jul 12, 2023

cpovirk commented Jul 12, 2023

cpovirk commented Jul 12, 2023

fmarot commented Jul 13, 2023 • edited

cpovirk commented Jul 13, 2023

cgdecker commented Jul 13, 2023

fmarot commented Jul 13, 2023

cpovirk commented Jul 14, 2023

Uli-Tiger commented Sep 26, 2023 • edited

rishiraj88 commented Sep 26, 2023

cpovirk commented Sep 26, 2023

cpovirk commented Sep 26, 2023

cpovirk commented Sep 27, 2023

fmarot commented Sep 27, 2023

Uli-Tiger commented Sep 27, 2023

cpovirk commented Sep 27, 2023

cpovirk commented Sep 27, 2023

fmarot commented Sep 28, 2023

cpovirk commented Sep 28, 2023

Uli-Tiger commented Sep 29, 2023 • edited

cpovirk commented Oct 18, 2023

fmarot commented Jul 13, 2023 •

edited

Uli-Tiger commented Sep 26, 2023 •

edited

Uli-Tiger commented Sep 29, 2023 •

edited