Temp files should be changed to another drive if detects SSD

Discussion in 'ESET Smart Security' started by shadowdogg, Oct 22, 2011.

Thread Status:
Not open for further replies.
  1. shadowdogg

    shadowdogg Registered Member

    Joined:
    Oct 22, 2011
    Posts:
    7
    Hi,

    Well I been doing a lot of downloads recently and noticed C:\Windows\Temp was getting bigger. As you guys know SSD really works badly creating files and deleting them as it needs TRIM to do its work.

    So I have been having degraded performance for a while, I do not mind the temp files but I don't see why you would put that in C:\Windows\Temp or not even allow me to change it?

    I have been using jdownloader. Not even sure how I can stop it making these files. Bit annoying that this has been going on behind my back. I would never have thought to check Windows temp folder for stuff relating to the anti-virus.
     
    Last edited: Oct 22, 2011
  2. shadowdogg

    shadowdogg Registered Member

    Joined:
    Oct 22, 2011
    Posts:
    7
    Ok, I updated to .94 and changed the system environment to my secondary hdd for temp and tmp and can't find it in either windows\temp or secondary hdd temp now :S

    Edit: Aha! They are back and in the new folder I set. Least eset uses what the system says :) But still for novice users perhaps it should do some intelligent temp reallocation. Still 700GB+ still been written to my SSD for no reason which is a bit annoying.
     
    Last edited: Oct 22, 2011
  3. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    I'm not aware of Windows offering a feature for automatic temp folder redirection if a SSD disk is detected.
     
  4. shadowdogg

    shadowdogg Registered Member

    Joined:
    Oct 22, 2011
    Posts:
    7
    No, ESET should do that because your system keeps making temp files in C:\Windows\Temp before analysing it for example when I am downloading with jdownloader. However, I changed the system environment slightly do that it now does it to my secondary hard drive but I wouldn't have had a clue you guys would be using Windows\Temp nor did I even know you made a file and then quickly deleted it.

    My SSD stats mainly because of ESET are:

    241: SSD Lifetime writes from host Number of bytes written to SSD: 1100 GB
    242: SSD Lifetime reads from host Number of bytes read from SSD: 783 GB

    My SSD is only a 60GB. The only real feature Windows does for SSD is TRIM and disabled automatic defragmentation for that particular drive when you look under the schedule
     
  5. King Grub

    King Grub Registered Member

    Joined:
    Sep 12, 2006
    Posts:
    814
    For those who do not know how to move your temp writes away from the SSD:

    Start menu -> Control Panel -> System and Security -> System -> Advanced system settings -> Environment Variables.

    Change both of the variable values in the top box to something else than your SSD, for example E:\Temp

    In the bottom box, scroll down to the TEMP and TMP variables and change those too (these are the Windows\Temp variables) to another drive. You can use the same as you used for the top box, E:\Temp again in my example.

    Click Ok and you're good to go. All temp writes will now be done on a mechanical HDD instead of your SSD, including the temp writes ESET did.
     
  6. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    I, for one, don't think that any software should temper with system variables and change them on its own.
     
  7. shadowdogg

    shadowdogg Registered Member

    Joined:
    Oct 22, 2011
    Posts:
    7
    No I am not saying that but Eset (you guys) have decided to use C:\windows\temp as its way of doing the real time protection.

    It should be

    if (ssd detected) {
    if (secondary mechanical hard drive detected) {
    set eset real time protection to X:\Temp
    }
    }

    That's all. I don't see how that should have to affect the system variables at all but what you will be doing is killing an SSD.
     
    Last edited: Oct 23, 2011
  8. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    No, ESET uses temporary folders configured in Windows setup like any other properly written application and this is not going to change. Other applications write to the temporary folder more frequently than ESET which also contains some kind of optimization causing that only extraction of certain files is done in the temporary folder.
     
  9. shadowdogg

    shadowdogg Registered Member

    Joined:
    Oct 22, 2011
    Posts:
    7
    Nice to know Eset has our backs when it comes to our devices then...
     
  10. dmaasland

    dmaasland Registered Member

    Joined:
    Nov 10, 2010
    Posts:
    468
    Why not just move the Temp folder then? That would move other software's temp files to a new location as well. Although you will most likely replace your SSD before you can damage it.
     
  11. xxJackxx

    xxJackxx Registered Member

    Joined:
    Oct 23, 2008
    Posts:
    4,050
    Location:
    USA
    This is likely a huge non-issue. It seems that many people with a SSD want to avoid actually using it at any cost. I treat mine like it's any other drive. By the time you move your pagefile and temp files and anything else that writes to it you have eliminated all of the benefits of having one to begin with.
     
  12. shadowdogg

    shadowdogg Registered Member

    Joined:
    Oct 22, 2011
    Posts:
    7
    Not temp files. Think about it, I have been downloading around 40GB a night for 3 nights (excessive maybe but my choice) each time that is perhaps creating about 20GB of stuff for no reason.

    An SSD is not like any drive, you have to treat it differently. AHCI must be enabled, other things have to be disabled. If you don't follow the things of having a SSD - pointless even buying it. The whole point of an SSD is its quick READ speed, not its WRITE speed imo.
     
  13. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    You have the option either to set the maximum size of scanned objects so that larger archives will not be unpacked to the temp folder or go for a more elegant and general solution for all applications - move the temp folder to another non-SSD drive. Generally the total amount of data written by ESET to the temp. folder should be significantly lower than the data written by other applications.
     
  14. dmaasland

    dmaasland Registered Member

    Joined:
    Nov 10, 2010
    Posts:
    468
    That was the case with the first generation SSD's, indeed. But the current gen SSD's have both high write and read speeds.
     
  15. shadowdogg

    shadowdogg Registered Member

    Joined:
    Oct 22, 2011
    Posts:
    7
    The reason for first-gen being high read because that was more important to achieve. Simply because the write speed is high does not necessarily mean it is designed to have tons of data being written to it all the time.

    I have already answered my question from the beginning anyway but not detecting SSD at beginning and telling me about it does put Eset lower in my opinion now tbh. Remember benchmarking which is really just making files and deleting them will cause your SSD to go slower and then requires around a week to recover if TRIM is supported.
     
  16. xxJackxx

    xxJackxx Registered Member

    Joined:
    Oct 23, 2008
    Posts:
    4,050
    Location:
    USA
    The only thing I have disabled is defrag. I have a pair of drives in RAID 0, no TRIM, 10 months of use, no babying the things, 525MB/s write and 550MB/s read. It would have been a pointless upgrade for me to have to work around using them. If you feel the need to have everything write to another drive to save your SSD by all means do so. Not trying to argue or anything, just not worth the trouble to me to have to do all of the workarounds to save them. They will run until they don't anymore. If I am dissatisfied with the lifespan I will go back to regular drives. So far they are fine.
     
Thread Status:
Not open for further replies.