Editing HTML file leaves temporary files lying about the place

[Adam Cameron.]

G'day

CFB 2.0.1, installed as stand-alone on Windows 7 Enterprise 64-bit.  Although this has been the case since CFB 1.0, and on various Windows installs.

Whenever I edit a HTML file (ie: with a .html extension), CFB creates  a temporary file in the same dir, eg: .tmp_charts.html.33659~ (the original file name is charts.html).  I've no problem with this - other than the fact it should not be necessary - but what I do have a problem with is that it does not tidy up after itself once it's done: the tmp files stay there.  This is a bit sloppy.

I'm sure (100% sure) I've raised with this with Adobe in the past, and raised a bug for it, but it's not on the bug tracker for some reason.

Can other CFB users test out what happens when they edit HTML files with CFB? Note: the tmp file does not show up in the navigator listing within CFB, but it is there in the file system if one looks with Windows Explorer.

I'm going to raise a bug again (done: 3328624), in the hope this can be fixed.  It's a minor thing, but I'm sick of accidentally committing rubbish to my source control because I forget CFB can't tidy up after itself.

Cheers.

--
Adam

[Miguel-F]

I have noticed those files as well, however my CFB seems to delete them after I shut down CFB (not when I close the file).  I am running CFB 2.0.0, Build 278082.  Are your temp files still lingering around even after shutting down CFB?

I agree with you, it definitely needs to clean up after itself.  I have also noticed that those temp files are created just by opening a HTML file, not only after editing one.

[Adam Cameron.]

Are your temp files still lingering around even after shutting down CFB?

Actually now that I doa quick test, they are not.  However I wonder if this is erratic because I do find the damned things accumulating.  And if they were always cleaned up upon close, they'd not accumulate.

Curious.

Still: they should just not be there in the first place.  They don't appear for any other file type that I am aware of.

--

Adam

[Miguel-F]

Curious.

Still: they should just not be there in the first place.  They don't appear for any other file type that I am aware of.

Agreed!

Come to think of it, I had another issue with CFB leaving bits around a while back.  Ahhh, now I can't remember exactly what the issue was.  I remember it had to do with mapping a networked drive.  When I would map a particular drive letter, say 'W', then start CFB it would create an entire folder hierarchy on there seemingly from a different server.  I know this because we have two different CF environments here; some server are running CF under JRun and others are running CF under WebSphere.  I only noticed this issue because I had mapped one of our JRun servers and all of a sudden it had portions of the WebSphere directory structure on there.  I think it had to do with a workspace in CFB but can't remember for sure.  I fixed it a while back by removing the offending setting in CFB.  Man, wish I could remember exactly what it was...

[Adam Cameron.]

Come to think of it, I had another issue with CFB leaving bits around a while back.

Your one doesn't sound familiar.  This is the worst one I've come across: http://forums.adobe.com/message/4555461#4555461

That's really annoying.

--

Adam

[Miguel-F]

Actually my issue was similar to that one.  It would create this deep folder hierarchy (because the WebSphere webroot is buried down deep in the folders) whenever I started CFB.  My colleague kept blaming me for an inadvertant copy-paste (or worse, a folder drag) but I swore I never did.  I finally tracked it down to CFB.  If I can remember my resolution I will post back.

[Adam Cameron.]

Cool cheers.  What's weird is that it's always that /circuits/scheduledTask/generate/includes/ dir that the p2 dir gets created in.  Even if I blow away  /circuits/scheduledTask dir, the whole subdir tree gets recreated again so that the "p2" dir has a place to be created.  There is absolutely nothing special about that /circuits/scheduledTask/generate/includes/ dir.  It's one of about 5000 dirs in that application.

--

Adam