Which language binding? The temp file creation and deletion is handled differently by
the different language bindings, so knowing which language you're using is important
in this case.

I use Java for the development.

My experience is the same while setup combo is win7/webdriver 2.0rc3/java. Can it affect
performance of the regression run?

A patch is attached that fixes this issue.

I'm not entirely sure how this fixes the issue: the "dir" being deleted is already marked
as a temporary filesystem and should be deleted when the jvm exits. Deleting the temporary
directory before the FirefoxProfile is actually discarded will cause some stability
problems too.

Am I missing something very obvious?

i think the problem is for long running server in grid for instance.

1. Yes, Francois is right, for a long running server (especially a virtual machine with
a small disk) it is a problem. Each profile can be several megabytes in size if some
FF plugins are used (e.g. firebug is about 2MB), several hundreds of tests causes "low
disk space" situation.

2. Actually, dir is a temporary directory that contains a profile extracted from json
string, but FirefoxProfile(dir) constructor copies content of this directory (webdriver*)
to a new profile  directory (anonymous*), and immediately after copying dir can be
safely removed. So, I think there is no need to wait until exit.

Any Updates on this issue, as i am doing evaluation of the framework to adopt it in
my team. each time i run a script it creates 19MB file in temp directory which can
be disastrous for system running multiple test cases.

I have encountered this issue as well. My long-running Selenium server, running on a
small VM with 8 GB of diskapce, is running out of diskspace due to temporary files
under /tmp.

I noticed that these files are cleaned up on JVM exit (probably because of the tmp
file status). However, for long-running server, this represents a leak, since the JVM
would not be restarted often.

Also interesting to note that I don't seem to have the same problem on Windows, only
on Linux do I see thousands of leaked profile directories (although my Linux usage
is a lot heavier, so this may not be a valid observation).

This issue was closed by revision r13935.

Reopened since r13935 was reverted in r13956 due to test break

Well, may be we have to remove the profile directory when driver.quit() is called? Will
it work for Grid? I'm having out-of-disk-space on my virtual machines almost every
day :(

Quit sounds good to me, especially if the tests dont break ;)

In the release note for Selenium 2.8, it is claimed that this issue of profile directory
filling up disk is fixed.

As far as I can tell, it is not fixed.

At the end of my test runs on the 2.8 Selenium server, even after all test sessions
are properly closed, a bunch of directories remain in /tmp:

drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895846/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895847/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895848/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895849/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895850/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895851/
drwxr-xr-x  6 root root  4096 Oct  9 02:00 anonymous1107044062167549014webdriver-profile/
drwxr-xr-x  6 root root  4096 Oct  9 02:00 anonymous2288986081707850643webdriver-profile/
drwxr-xr-x  6 root root  4096 Oct  9 02:00 anonymous3928139591340740449webdriver-profile/
drwxr-xr-x  6 root root  4096 Oct  9 01:58 anonymous425239302836435538webdriver-profile/
drwxr-xr-x  6 root root  4096 Oct  9 01:56 anonymous5847048534096526317webdriver-profile/

The anonymous* directories are deleted only upon JVM termination for Selenium server.

Furthermore, in the 2.8 release, I now see a new kind of leaks - the integer based
directories are not cleaned up at all.

This is after the server/JVM has terminated:

drwxr-xr-x  2 root root  4096 Oct  9 01:57 1318110895845/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895846/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895847/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895848/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895849/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895850/
drwxr-xr-x  2 root root  4096 Oct  9 01:59 1318110895851/

These integer directories are empty inside.

Fixed (again) in r14142

I don't think this issue was fixed. I'm using Grid/WD version 2.11.0 and the Grid machine
dir "C:\Users\qauser\AppData\Local\Temp" is filled with the following folders "webdriver113516513935198274duplicated"
which contains my custom FF profile. Each folder is about 12MB. After a week or two
my Grid server suffered from "low disk space" and i realized the temp folder reached
19GB!!!
Now, i guess i can write a small script which deletes those folder every once in a
while but i think this should be fixed in WD.

BTW, i'm using Java if this info is important.

@jongler, I think you are right, there are actually multiple issues hiding inside this
thread, and the /original/ issue is not fixed. I'm reopening, this is for the specific
leak associated with the method FirefoxProfile#fromJson (serialized profiles on remote
node)

Is there any estimation on when this bug is going to be fixed?

Deleting files/directories upon JVM exit is unacceptable for some environments (Like
mine). I run routine firefox tests, and I load in Firebug -- Each anonymous profile
is ~22MB. And this is a service I run, not a one off application.

I've resorted to patching the FirefoxProfile to track it's profile directory, and FirefoxWebDriver's
close method to delete the dir from the FirefoxProfile (if it's anonymous).

Why isn't this the natural case?

I just downloaded the latest C# WebDriver 2.17 and I am having this issue. I'm not happy
Bob!! The cog on the wheel is broken.

I was having the same problem with WebDriver 2.14 and 2.18 being used inside of some
JUnit tests.

My fix was to add the following inside my tearDownAfterClass method.

@AfterClass
    public static void tearDownAfterClass() throws Exception {
        TemporaryFilesystem tempFS = TemporaryFilesystem.getDefaultTmpFS();
        tempFS.deleteTemporaryFiles();
        driver.quit();
    }

Hope this helps.

Hi clayton,

This is a nice solution but it won't work when running tests in remote, using grid.
Am i right?

Hello Kristian,

I think the subject of this issue should be "*Remote*WebDriver does not delete firefox
profile directory", and I think I have found the root cause of this issue (which still
exists on trunk):

org.openqa.selenium.remote.server.DefaultSession creates a temporary directory named
after the session id (and properly deletes it when the session is closed).
So I guess the assumption is that code in the session should use TemporaryFilesystem.getTmpFsBasedOn(SESSION_TMP_DIR).

But src.org.openqa.selenium.firefox.FirefoxProfile.fromJson() is not aware of this
and instead uses TemporaryFilesystem.getDefaultTmpFS() to place its profile copy, and
this never gets deleted.
However, I'm not sure that FirefoxProfile *can* be aware of the Session, since it may
or may not be running under a RemoteWebDriver.

I can't really propose how to fix this issue; maybe the FirefoxDriver needs to explicitly
remove its Profile when quitting?

Hm, this is still a pain ass bug after so many months!?!

Selenium 2.23.1 on Win XP, Chrome 19.0184.56m/Chromedriver 20.0.1133.0
Also a lot of scoped_dir* directories in Temp.

any updates on the "scoped_dir* directories not cleaned up" issue with ChromeDriver?
It fills up disk space in our CI environment and is a problem we really want to tackle.

@alex.ikhelis: Please create a new issue in the chromedriver issue tracker: http://code.google.com/p/chromedriver/issues/list

hmm... looks a bit strange that developers of testing tools seemingly don't write regression
tests for their bugfixes.

Is there regression?

Please reopen. This is not fixed. I just deleted tons of these folders each of them
about with a size of approximately 30 MBytes.

I'm using WebDriver 2.25.1 (.NET version) with FireFox 16.0.2. Operating system is
Windows 7 (64bit), latest patches installed.

********************
You can get this problem by failing to issue a .quit() at the end of your session.
 If you just end with a .close() it won't do a cleanup.  We were seeing this exact
same problem (FireFox on Win7 browser cache/profile being dumped to a appdata/local/temp
folder for every test run), but by adding the .quit() to the end the problem went away
and now we get clean runs.
********************

@tjul...@dyn.com Tried what you suggested and your workaround appears to work. Thank
you!

We are seeing this issue on Win7 using selenium-server-standalone-2.26.0. We are also
calling Quit() on the driver before exiting, yet our node disks are filling up with
the following types of folders/files in our \Users\<username>\AppData\Local\Temp folder:

(1) Folders with names like "1343943823037"
I assume these are session id folders. These folders are empty, but they exist even
after shutting down selenium node.

(2) Folders with names like "anonymous1972864079409089672webdriver-profile"
These folders are about 8 MB each.

(3) Folders with names like "scoped_dir14656_4658"
These folders are mostly empty. Sometimes there is a 0 byte chrome_debug.log file.

(4) Folders with names like "webdriver-ie9198441489016361573"
These folders all seem to be empty.

Even after shutting down the selenium node, these files persist. They are consuming
a most of our drive and we have to keep deleting them. This is an issue that needs
to be resolved. Please re-open this issue.

I am seeing the scope_dirxxxx left around on Win7 running 2.28 (local WebDriver server,
not remote node).  When Chrome browser is started, it created two scope_dirxxx (with
different sequence number): one empty and the other containing two subfolders "Default"
and "Temp" and 5 text files (chrome_debug.log, EULA file, etc.).  

When Chrome is stopped (.close() and .quit()) called, the empty scope_dirxxx was delete
as expected, but the other folder scope_dirxxx was left behind (about 8mb).

This is repeatable.

I am running the latest chromedriver.exe.

@45 You should report this in the ChromeDriver tracker: 

  https://code.google.com/p/chromedriver/issues/list

I have been using a workaround that upon testcleanup we would clean out all those files.
However, now that we started using Grid, I think we are accidentally cleaning out the
folders that are also still in use. To continue to use this solution more effectively
(until the root cause is fixed), is there a way to find the folder that was created
per test? This way with that reference I would be able to delete the folder that would
no longer be used.

I have the same problem.

When Chrome browser is started, it create two folders scope_dirxxx (with different
sequence number): one empty and the other containing two subfolders "Default" and "Temp"
and 5 text files (chrome_debug.log, EULA file, etc.).  

When Chrome is stopped (.close() and .quit()) called, the empty scope_dirxxx was delete
as expected, but the other folder scope_dirxxx was left behind (about 8mb).

This is repeatable in interval of 15 minutes. After a few hours, i dont have no more
disk space.

I am running the latest chromedriver.exe.

Selenium version: Selenium-Java 2.35
OS: XP
ChromeDriver (v2.2)
Browser: Chrome
Browser version: 29.0.1547.57

I got a strange problem. I was running ChromeDriver on a test and found the hard disk
full the next day. After cleaning out the System Temp files using Ccleaner, I re-booted
the machine. However, something is still generating scoped_dirxxx folders and writing
to them. 

We are seeing the same issue sas well.  Is there anyone working on this?

No-one here is working on the chromedriver issue, it is not part of this project. If
chromedriver leaves files, it has to be fixed there, as per coment #46

Hello, I'm working with FF and windows Server 2008 64 bits. This problem has not been
fixed, so I can't use Selenium WebDriver any more. My Hard drive is full and also My
RAM, cause selenium doesn't kill Firefox.

Regards

>>> cause selenium doesn't kill Firefox

There is no "auto-stop". Do you call driver.quit() in the end?

I'm Sorry something was wrong in my code. All is ok.
Nevermind..

I am seeing this issue. As my testing requires installing a FF plugin, and comparing
Plugin enabled browser with clean browser (No plugin). This is blocking current testing.
A workaround using a compiled .exe is currently being used to install the plugin and
preserve the profile name, but not our ideal solution.

I'm also still having the exact same issue using Windows 7, C# and the WebDriver for
Firefox version 2.39. I have resorted to calling WebDriver.Close() only and then manually
delete the profile directory. Some code to show this:

//in constructor of WebDriver wrapper class: 
var profile = new FirefoxProfile(Config.FireFoxProfilePath); //reusing an old FireFoxProfile
var _profileDirectory = profile.ProfileDirectory; //If I understand this correctly,
this is the actual temp profile directly as created based on the constructor template
folder? 


//in dispose method:
WebDriver.Close(); //instead of WebDriver.Quit();
Directory.Delete(_profileDirectory, recursive: true);  

The problem is, besides that WebDriver.Quit fails due to an exception, is that I have
to have a try catch around the Directory.Delete statement due to an IOException telling
me that ""Access to the path 'csharpformatters@seleniumhq.org.xpi' is denied.". Though
when checking the file with a Windows Explorer plugin like Unlocker, it reveals that
there are no locks on the file. And there is no problem deleting the file manually
in the the File Explorer. Running Visual Studio as an administrator makes no difference.

When using the WebDriver.Quit() method instead, it seems, with this version of the
WebDriver to catch the exception since exactly the same files remains after the execution.
So my manual Delete statement I guess is similar to what is under the hood in WebDriver.Quit()
(I have not checked obviously). But the problem remains that all files are not deleted.
The memory footpring seem to be reduced to <800 KB which which is better than 20+ GB
but still not good enough for a test server running tests often. 

Exception in thread "Thread-4" java.lang.NullPointerException
    at org.openqa.selenium.io.FileHandler.delete(FileHandler.java:132)
    at org.openqa.selenium.io.FileHandler.delete(FileHandler.java:133)
    at org.openqa.selenium.io.FileHandler.delete(FileHandler.java:133)
    at org.openqa.selenium.io.FileHandler.delete(FileHandler.java:133)
    at org.openqa.selenium.io.TemporaryFilesystem.deleteTemporaryFiles(TemporaryFilesystem.java:129)
    at org.openqa.selenium.io.TemporaryFilesystem$1.run(TemporaryFilesystem.java:36)

The way I found to get around this issue was to wrap my instance of the webdriver in
a "Using" clause and cleaning the profile.   
I performed a few things to speed up my tests.  #1. Made my custom profile as small
as possible and only what was needed. #2. Generated a port to avoid not being able
to bind to a locking port. #3. Called profile.Clean(); after my tests are completed.

Windows 7 / Windows Server 2008. C#. Selenium Webdriver 2.35
    public static void Test() 
    {
        FirefoxProfile profile = new FirefoxProfile(CustomProfile);
        //Generate a Port for the profile to use (I was having binding issues with
multiple tests)
        Random genPort = new Random(); 
        profile.Port = genPort.Next(7000, 7500);
        using (IWebDriver driver = new FirefoxDriver(profile))
        {
            //Perform my Test 
            //Quit my driver
            driver.Quit() 
        }
        //Call Profile.Clean() to delete any profiles that may have been generated.

        profile.Clean(); 
    }

Using this method, I have been able to keep my servers clean of Anonymous webdriver
profiles. Previously I had my drives becoming full rather quickly, but decreasing the
size of the profiles helped dramatically. (50 mb per to 2.5 mb per). 

The NullPointerException in FileHandler.delete is caused by the code not checking the
return value of File#listFiles() properly (it can return null). I've submitted a pull
request here:

https://github.com/SeleniumHQ/selenium/pull/241

Hello,

I also got the NPE mentioned in a comment above and managed to find out the cause.


I was trying to make the cleanup on shutdown hook. But the files created by the TemporaryFilesystem
are scheduled for deletion on exit by using: File.deleteOnExit() which also deletes
the files on a shutdown hook that runs concurrently with mine.

Maybe this helps you identify some other issues in this area.