Jump to content

marmite

Experienced Members
  • Posts

    867
  • Joined

  • Last visited

Posts posted by marmite

  1. Good point I think for once someone actually means windows explorer.... anyway IE7Pro wasn't too bad, but not good enough to give up firefox :)

    Ah yes, I think you're right ... I was following your lead with IESpell, lol (lame excuse ;)). Just carrying on off topic then, I actually went back to IE when 7 came out ... IE7Pro just made it better. Horses for courses as usual :)

     

    I don't actually use any extensions for Windows Explorer ... think I might take a look at what's recommended here.

  2. The only problem with malware is that the more clever jerk will be able to dodge some of these scans because they rename the file on the sly so that a scan misses it but that is rare granted.

    I would have thought that the name of a file alone is rarely important; it's the signature of the file content that will be recognised as malicious.

  3. Where does CRC32 fit into all of this? When would you opt for CRC32 as opposed to MD5 or SHA?

    They are all just different algorithms. If you think that effectively they are just checksums that use different calculations to derive the hash.

     

    The one you tend to see very commonly for file hashing is MD5 (128 bit). SHA1 is more secure at 160 bit. CRC32 is shorter (32 bit?) and less secure. By 'secure' in this context I mean the likelihood of a collision; i.e. two different values producing the same hash.

     

    With MD5 this is very unlikely to be a problem for a file hash. The chances of this happening with CRC32 must be greater, but possibly still not significant.

     

    If you're using hashes to verify files you're downloading then you have to go with the hash you're given. If you go to filehippo and look at all of the versions there you will see MD5 hashes (on the 'Technical' tab). The thing with hashes is that they take time to calculate. So the more secure the hash algorithm, and the more or bigger the files you're hashing, the longer the time they'll take to compute. MD5 is an excellent compromise.

     

    If you're using hashes on your own PC to see whether files have changed then the algorithm is less important. A few bytes difference in file versions will give you a different hash, no matter which algorithm you're using.

     

    Karen's hasher is great for processing files en masse. The tab tool I mentioned is great for verifying a file download hash.

  4. I think it depends on its use. From what I've read then for file verification it's as good as you'll need. It's only when you have security or cryptographic considerations where you'd have cause for concern - both MD5 and SHA-1 have known vulnerabilities.

     

    A coupe of decent wiki articles - http://en.wikipedia.org/wiki/MD5 and http://en.wikipedia.org/wiki/Md5sum.

     

    Hashtab is a really good app that puts a file hashes tab on the file properties page. It has a wide range of algorithms available, and provides an easy comparison mechanism. http://beeblebrox.org/

  5. Quick scan vs full scan

     

    "All it does is scan more locations on the hard drive(s), thus allowing it to pick up traces it might have otherwise missed, but again, even that's rare because the quick scan is designed to look in all the places malware likes to hide."

     

    Seems like full scan is pretty pointless according to the malwarebytes team

    It would be nice if they would change the text on their GUI then. To say that a quick scan only (and I quote) "scans for the most common types of malware" is misleading if it's actually using the full set of definitions.

  6. I don't think its a matter of time its a matter on how bad it is.

    Agreed - if it needs defragging then defrag it. If you haven't defragged for a year but it doesn't need it then leave it alone!

  7. I imagine quick scan checks the most likely place where malware would hide. Where as deep scan checks the whole computer or which ever directorys you choose it to look.

    That's what I thought. But if you look at the description in MBAM under 'Perform Quick Scan' it also suggests it's only scanning for the most common types of malware.

  8. I think Andavari touched on this...

    If you open a jpeg and file "save as" it may/will drop bytes again (I think it's because a save as will run the compression again).

    That's certainly my experience - that's why I don't use that method to 'copy' a jpeg.

     

    :: Feel free to correct/clarify any of my info, :) ::

    Nope - sounds like everyone is agreeing ;)

     

    Now, what was the topic again ... ah yes 'best media player'!! :huh:

  9. The thing I dislike about prefetch ... is that it catches a lot of dross. Just look at Layout.ini and see what it includes in its auto-defrag and loadup routines: temp int files, sys restore, lang files i shall never use etc.

    Interesting point. My Layout.ini is huge compared to the number of prefetch entries. Though it contains a lot of duff entries ... software I've never even had installed (due to it being an OEM image I guess).

     

    The only time I've ever bothered with prefetch is where I've had problems at work that have required me to clean it.

     

    Might look at this Layout.ini now out of curiosity though ;)

  10. A file will only loose quality after it is saved as a lower quality file type (lossy) jpg/gif.

    I'm not even sure that's the case. If you do 'Save As' in the same piece of software, you will end up with different file sizes (at least, in the software I've tried). Only a matter of bytes; but it's not an exact copy.

     

    If I am concerned about quality the only way I will copy a jpeg is with a system file copy.

     

    Gifs are lossless - just have a lower colour range.

  11. The only problem with ccleaner's mechanism (if the article is accurate) is that ccleaner deletes prefetch older than two weeks. I wouldn't call that 'old'. Perhaps the devs could confirm that cut-off point?

     

    I was not advocating deleting everything in my first reply - however if that's the approach the OP chooses to take it's probably easier to just disable it in the first place.

     

    I don't regularly clear prefetch at all - I see no benefit in doing so.

  12. Not quite :). What I am saying is that if you save a file that uses a lossy compression file format, like a jpeg, you will lose quality compared to the original. Basically the loss of quality actually takes place at the time at which you save the file because that's when the lossy algorithm is applied.

     

    So for example, if you are editing a photograph, it's always better to work with a lossless format. So I might decide to do all my edits in say lossless TIFF, so each time I edit the actual picture quality will be the same as the last. As you pointed out earlier, these files get very big. So I might keep the first one, in case I want to start all over again. I will definitely keep the last one ... that becomes the 'master' copy at maximum quality.

     

    But TIFFs can be huge, so chances are I'll want to work with a jpeg if say, I want to send a high quality copy to a friend. so I will save that TIFF (create a new file) as a high quality jpeg. However, if I want to do a low-res and/or low quality copy to put on the web, I won't take it from the jpeg, I'll do a different copy from the TIFF - because that will have better quality than if I'd taken it from the first jpeg. Not a huge difference (because the first jpeg was high quality) ... but that's where quality starts to go once we keep taking jpegs from jpegs.

     

    Doing a Windows or system file copy of a jpeg (or any other file) is fine ... that's just a byte for byte copy. You can copy those around to your heart's content and you won't lose quality.

     

    So text files aren't normally compressed, and even when we use zip compression it uses a lossless format so that when we unzip we get exactly the same data back out.

     

    In fact most data we work with on PCs is lossless - some will be compressed, like zip archives, but most isn't. Raw audio or pictures or video takes up a huge amount of space - so we use file formats with some form of compression in order to make them smaller ... and that's when you have to be careful if you do a lot of editing.

     

    This doesn't mean jpegs are bad - far from it. Jpegs and other lossy formats all have a time and a place ... it's just being aware of the pitfalls :) Look at mp3s, which are also lossy ... everyone has 'em, but if you were producing music you wouldn't work with those as master copies.

     

    Here's a better link re pics ... http://en.wikipedia.org/wiki/Lossy_compression

  13. I have seen pictures erode in jpeg format. When I first noticed it many years ago I ran tests on Jpegs.

    If you keep saving the same JPEG file the quality will deteriorate - and yes you can see that when viewing each subsequent generation of the file.

     

    If you open file A (a JPEG) and save, then save it again, and again, the quality will gradually deteriorate because the compression algorithm reduces the quality of the image each time.

     

    If you open file A, save that as file B, save that as file C, the quality of file C will be less than that of B which will be less than that of file A. But the quality of the file A image will remain the same and will not erode over time on its own.

     

    Any lossy file format will behave in the same manner.

  14. I have always hated Jpeg because it loses quality (erodes) over a short space of time in drive storage.

     

    A Raw file should outlive a MP3 file for instance.

    I don?t have MP3 files but I have been told you can sometimes hear a change in the time signature and it loses solidity.

    No file 'loses' image or audio quality sitting on your drive.

     

    You are correct to say that certain file types, those that exhibit what is known as lossless compression, are best as a 'reference copy' of a file ... they will always have optimum quality. If you save a (lossless) BMP as a (lossy) JPEG, you will lose some quality. That's why it's always better to have your original copy of (e.g. photo) files in something like RAW, BMP or lossless TIFF. If you want to publish a copy of your photo online, take an appropriate resolution JPEG because it's much smaller ... but always hang on to your original lossless copy.

     

    Similarly, if you're editing a photo, work in lossless format. Don't keep saving as a JPEG ... you'll lose quality each time you save, even on 'maximum' quality.

     

    A couple of articles ... http://en.wikipedia.org/wiki/Audio_file_format, http://en.wikipedia.org/wiki/Lossless_data_compression.

  15. Hi toby7

     

    Prefetch is listed under 'Advanced' on the 'Windows' tab ... top of the list in fact.

     

    So you won't agree with this article then. Do you expect everyone to take your word for the 'uselessness' of prefetch data or were you going to justify your assertion? ;)

     

    If you don't want to use prefetch at all why don't you disable it?

  16. I've had a similar problem previously when I've resized a partition. The process went slightly awry because the product I used had changed the partition table to (effectively) mark the partition 'out of use' but then it didn't get changed back again after the resize. All I had do do was find a utility to reset it ... literally a matter of changing a couple of bytes. If you're technically savvy it might be worth having a look at this. I used something (free) called Test Disk for Windows.

  17. thank you very much! but arent there a way to get programs back to the un-install list?

    Do you mean you did a 'Delete' from the ccleaner 's list? If so, I don't know what sort of an installer Norton has but if you run that there's usually an option to 'repair' an installation. If there is that should hopefully add the installer entry back into the registry. It should then reappear in Add/Remove Programs and the ccleaner list.

     

    Edited to add: crossed in the post with Andavari ... his reply is more comprehensive.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.