1. Computer problem? Tech Support Guy is completely free -- paid for by advertisers and donations. Click here to join today! If you're new to Tech Support Guy, we highly recommend that you visit our Guide for New Members.

moving the Java cache in win 7

Discussion in 'Windows 7' started by lopati, Jan 25, 2011.

Thread Status:
Not open for further replies.
Advertisement
  1. lopati

    lopati Thread Starter

    Joined:
    Jan 25, 2011
    Messages:
    4
    I saw an old thread (now closed) where somebody had asked how to move the java cache.

    No answer was given there, nor in many other forums. Some "experts" even went on to claim it was not even possible. Well, ignore the "experts" and "gurus" that say otherwise, it is possible, and it's easy.

    Reference: info can be found at:
    http://download.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/properties.html

    FYI: Here is what I did:

    1. to be safe make sure no java procs running

    2. go to the dir \Users\<yourname>\AppData\LocalLow\Sun\Java\Deployment

    3. edit the file deployment.properties
    (I used notepad++)

    4. add the lines (I put these near the top)
    deployment.user.cachedir=c:\\tmp\\sheet
    deployment.system.cachedir=c:\\tmp\\sheet
    deployment.user.logdir=c:\\tmp\\sheet
    deployment.user.tmp=c:\\tmp\\sheet

    --notes:
    leading spaces above for readability only.
    I pre-created c:\tmp\sheet (not really "sheet", but something similar)
    You do need to use double \\'s

    5. save the file

    6. remove the old cache, log etc dirs in \Users\...\Deployment.

    I tested it, it works, (and now I can clean up those "sheet" java temp files much more easily).

    Final notes:
    The change dir still stays greyed out in the java control panel, but it does show the new location.
    After editing it, I made the deployment.properties file R/O, just to be safe.
     
  2. dvk01

    dvk01 Derek Moderator Malware Specialist

    Joined:
    Dec 14, 2002
    Messages:
    47,872
    While that might work, it is extremely dangerous and has the possibility of allowing a malformed java applet or dangerous file to be run without user knowledge or interaction

    The local low folder in youir app data profile means that it has low rights to prevent problems whereas items in temp folders are system available that is available to anyone

    Why don't you just use the very simple recommended method to empty java cache

    clear your Java cache as shown http://www.java.com/en/download/help/5000020300.xml
     
  3. lopati

    lopati Thread Starter

    Joined:
    Jan 25, 2011
    Messages:
    4
    No I diagree, absolutely not dangerous at all, I mane how can it be dangerous if I'm the only person using this computer?
    Secondly if I should click on a bad item that downloads some java applet it doesn't matter where it is temped, locallow, /tmp or on a punchcard - it'll run regardless.

    If you are thinking of the case where some how a bad applet is silently placed in the temp dir (note, wherver it may be) then how does it get activated, for sure I'm not going into the temp dir and clicking on items to see what happens. Heck even randomply clicking on valid items can cause problems if not initialised properly.

    No, the threats you speak of can only happen:
    1. If you are dumb enough to click on a viral link
    2. if you are dumb enough to click on items stored in any temp dir wherever that dir may be.
    And these apply no matter where your temp files are stored.

    As to mixing configuration files and temp files together is plain stupid, and in production environments is a absolutely a worst practice. I've separated these many times for customers (documented and explained) and they all agree it's the correct action and some even made a corporate policy if it already didn't exist as such.

    For reference I've been using the internet since 1987, rarely run a virus scan unless required by customers before connecting my laptop for a job, never have antivirus running full time (it's just a plain waste of resource), and never, yes never had a single infection, and I've clicked many interesting links and downloaded hundreds of programs in that time.

    Finally
    1. The notes on how to move the cache were from Oracle, your "dont touch it" scaremongering is both wrong and does not help anyone.
    2. Computers dont infect computers, stupidity does.
     
  4. lopati

    lopati Thread Starter

    Joined:
    Jan 25, 2011
    Messages:
    4
    I should add in good corporate policy temp files are moved to a separate *secure* location (so they can not be browsed by ordinary users), and log files to another separate secure location - but defintely must be separated from configuration directories. My earlier example was on my own laptop (only user).
     
  5. dvk01

    dvk01 Derek Moderator Malware Specialist

    Joined:
    Dec 14, 2002
    Messages:
    47,872
    In W7 anything is allowed access to temp files and it is very common for a remote trojan on a website for example to drop files in temp & potentially be able to run them
    anything in locallow can only be accessed by a program installed on the computer with the correct digital signature
    Moving java cache overrides that protection. That is why java trojans & exploits have so little impact on W7 computers compared to earlier versions ( even when out of date java is installed)

    You cannot directly click an applet in java cache in local low either accidenatally or deliberately to run it . You can in C:\temp


    You can do whatevere you want on your own computer but it is irresponsible to publicize methods that open avenues of attack
     
  6. lopati

    lopati Thread Starter

    Joined:
    Jan 25, 2011
    Messages:
    4
    > You cannot directly click an applet in java cache in local low either accidenatally or deliberately to run it . You can in C:\temp

    Bzzzt, just did exactly what you said was not possible: clicked on items in local low (after checking they were safe of course), and they ran!

    As I said, doesn't matter where the stuff is, if people are dumb enough to click on random items it can cause problems.

    To be fair you attempted to provide a reason why I'm wong, here's one of mine that shows I'm right: A very old common attack was to fill temp volumes. This can mean updates to config files and other important state tracking files (from within the application, i.e. runstates, restart points) may not be saved, leaving applications in an unstable state. Yes it is mainly used an exploit to disable a computer rather then gain access, but in any case production environment computers should not be allowed to fail because the administrator was too lazy to take simple precautions.

    Thanks for your advice but I'll stick to my good, no sorry make that industry best practice.
     
  7. Sponsor

As Seen On
As Seen On...

Welcome to Tech Support Guy!

Are you looking for the solution to your computer problem? Join our site today to ask your question. This site is completely free -- paid for by advertisers and donations.

If you're not already familiar with forums, watch our Welcome Guide to get started.

Join over 733,556 other people just like you!

Loading...
Thread Status:
Not open for further replies.

Short URL to this thread: https://techguy.org/976845