Javascript error: disk is full

Question

I'm on linux, so no way to test this now, but the files in question are not stored in browser cache, but in

Note: As of IE 10 this no longer holds water. Ref. edit 2 below.

W7+: %HOMEPATH%\AppData\Roaming\Microsoft\Internet Explorer\UserData
   # c:\users\*user-name*\...

XP : %HOMEPATH%\Application Data\Microsoft\Internet Explorer\UserData
   # c:\Documents and Settings\*user-name*\...

Or, I guess, this one also work (as a short-cut), :

%APPDATA%\Roaming\Microsoft\Internet Explorer\UserData

Modify or delete the files there.

Note that the files are tagged as protected operating system files, so to view in Explorer you have to change view to include these. If you use cmd, as in Command Prompt you have to include the /a flag as in:

dir /a

Edit 1:

Note, that index.dat is the one holding information about allocated size etc. so it won't (probably) help to only delete/move the xml files.

Edit 2:

OK. Had a look at this in Windows 7 running IE 10.

In IE 7 (on XP) the above mentioned path have an index.dat file that gets updated on save by userData. The file holds various information such as size of the index file, number of sub folders, size of all files. Then an entry for each file with a number identifying folder, url where it was saved from, name of xml file, dates etc. Wrote a simple VBScript parser for this, but as IE 10 does not use the index.dat file it is a waste.

Under IE 10 there is no longer various index.dat files but a central database file in:

%APPDATA%\Local\Microsoft\Windows\WebCache\

On my system the database file is named WebCacheV01.dat, the V part seems to differ between systems and is perhaps an in-house version number rather then a file type version.

The files are tightly locked, and as such, if one want to poke at them one solution is to make a shadow copy by using tools such as vscsc, Shadowcopy etc.

Anyhow, hacking WebCacheVxx.dat would need a lot more work, so no attempts on that on my part (for now at least).

But, register that the file gets an entry with path to the old location – so e.g. on write of someElement.save("someStorageName");, WebCacheVxx.dat gets an entry like:

...\AppData\Roaming\Microsoft\Internet Explorer\UserData\DDFFGGHH\someStorageName[1].xml

and a corresponding file is created in the above path.

The local container.dat, however, is not updated.

userData

As for the issue at hand, clearing localStorage will not help, as userData is not part of that API.

Can not find a good example on how to clear userData. Though, one way is to use the console.

Example from testing on this page:

Save some text.

Hit F12 and enter the following to clear the data:

/* ud as an acronym for userData */
var i, at,
    ud_name = "oXMLBranch",
    ud_id   = "oPersistText",
    ud      = document.getElementById(ud_id); 

/* To modify the storage one have to ensure it is loaded. */
ud.load(ud_name); 

/* After load, ud should have a xmlDocument where first child should hold 
 * the attributes for the storage. Attributes as in named entries. 
 *
 * Example: ud.setAttribute("someText", "Some text");
 *          ud.save(ud_name);
 *
 *          XML-document now has attribute "someText" with value "Some text".
 */
at = ud.xmlDocument.firstChild.attributes;

/* Loop attributes and remove each one from userData. */
for (i = 0; i < at.length; ++i) 
    ud.removeAttribute(at[i].nodeName); 

/* Finally update the file by saving the storage. */
ud.save(ud_name);

Or as a one-liner:

var ud_name = "oXMLBranch", ud_id = "oPersistText", i, at, ud = document.getElementById(ud_id); ud.load(ud_name); at = ud.xmlDocument.firstChild.attributes; for (i = 0; i < at.length; ++i) ud.removeAttribute(at[i].nodeName); ud.save(ud_name);

Eliminating one restriction

There are some issues with this. We can eliminate at least one, by ignoring the ud_id and instead create a new DOM object:

var i, at,
    ud_name = "oXMLBranch", 
    ud      = document.createElement('INPUT'); 

/* Needed to extend properties of input to include userData to userdata. */
ud.style.behavior = 'url(#default#userdata)';

/* Needed to not get access denied. */
document.body.appendChild(ud); 

ud.load(ud_name); 
at = ud.xmlDocument.firstChild.attributes; 

for (i = 0; i < at.length; ++i) 
    ud.removeAttribute(at[i].nodeName); 

/* Save, or nothing is changed on disk. */
ud.save(ud_name);

/* Clean up the DOM tree */
ud.parentNode.removeChild(ud);

So by this one should be able to clear userData by knowing name of the storage, which should be same as the file name (excluding [1].xml) or by looking at the page source.

More issues

Testing on the page mentioned above I reach a disk is full limit at 65,506 bytes.

Your problem is likely not that the disk is full, but that a write attempt is done where input data is above limit. You could try to clear the data as mentioned above and see if it continues, else you would need to clear the data about to be written.

Then again this would most likely break the application in question.

In other words, error text should have been something like:

Write of NNN bytes is above limit of NNN and not disk is full.

Tested by attaching to window onerror but unfortunately source of error was not found:

var x1, x2, x3, x4 ; 
window.onerror = function () { 
     x1 = window.event; 
     x2 = x1.fromElement; // Yield null
     x3 = x1.srcElement;  // Yield null
     x4 = x1.type; 
};

End note

Unless the clear userData method solves the issue, I do not know where to go next. Have not found any option to increase the limit by registry or other means.

But perhaps it get you a little further.

There might be someone over at Super User that is able to help.