top of page
  • Writer's pictureTroy Web Consulting

Bugs with reading spreadsheets from ram:// disk

So this week I had to create a utility to whip together a few spreadsheets, zip them up and provide a download link. There are (2) good reasons (and probably more) to use the RAM disk for storing the files during the processing ISO traditional disk:


  1. Disk bloat: One of the challenges with these sorts of utility apps is orphaned files on the server and after a few months, years, disk space gets scarey. Of course we can clean up the files with a <cfdirectory action="delete" /> but there are times when you simply can't rely on that - an error may halt processing, the code to cleanup may not fire and there are those nasty little orphans again! Oh, and then there is the "I'm really lazy" part of programming that, during development, when I'm aborting processing all over the place (for debugging purposes) - well, i just don't want to see all those files getting orphaned...

  2. Performance: Disk I/O is slow, memory allocation is fast. 'nuff said.

ColdFusion 9 introduced the ram disk - basically, a "virtual"disk drive that CF treats like a regular disk system: You can write, read, delete, even <cfinclude />. Anyway, use "ram://" as the "drive" specification and create *nix style paths and you are all set.

What are the cons? Well, the ram disk is volatile - if the server reboots it's all gone. There are some other limitations, like how much ram it will tie-up and the (lack of) restrictions on who can access what (it doesn't use traditional O/S ACLs). But for what i needed, it was perfect.


And so life was good. I was cranking out the spreadsheets (by copying existing templates) and was able to zip them up and deliver them through <cfcontent /> just fine, and dang fast. Then I went back and tried to actually access the spreadsheets after i copied them, to update some data in them before creating the zip. That's when I hit this little snafu.


It appears that when you write a spreadsheet to the ram disk, ColdFusion cannot access it through the spreadsheet functions or the <cfspreadsheet /> tag. I guess I'm not surprised - I'm not sure what (java) utility CF is using under the covers to access the spreadsheets, but i suspect the drivers cannot accept a ram disk file path. Bummer.

Back to using disk and hoping like hell my cleanups do their thing...

here is a sample code you can run to see it yourself:

<cfscript> sep = createObject("java", "java.lang.System").getProperty("file.separator"); folder = "AF2E3351-1422-52FB-568E3B79A02D455F"; disk = {"dir" = "#expandpath('./')##folder#","list"="","fname"="","spreadsheet"="","err"="no errors"}; ram = {"dir" = "ram://#folder#","list"="","fname"="","spreadsheet"="","err"="no errors"}; if(NOT directoryExists(ram.dir)) directoryCreate(ram.dir); if(NOT directoryExists(disk.dir)) directoryCreate(disk.dir); source = listAppend(expandpath("./"),"template.xlsx",sep); disk.fname = listAppend(disk.dir,"spreadsheet.xlsx",sep); ram.fname = listAppend(ram.dir,"spreadsheet.xlsx","/"); fileCopy(source,disk.fname); fileCopy(source,ram.fname); ram.list = directoryList(ram.dir); disk.list = directoryList(disk.dir); try{ disk.spreadsheet = spreadsheetRead(disk.fname); } catch(any e){disk.err = e.message;} try{ ram.spreadsheet = spreadsheetRead(ram.fname); } catch(any e){ram.err = e.message;} writedump(disk); writedump(ram); </cfscript>
bottom of page