What are these files and folders?

Discussion in 'Computer Information' started by Jeff Strickland, Jan 30, 2014.

  1. df84b7afba5b2c94f3194b06d0a5265b


    I have several dozen of these kinds of files and folders, mostly folders I
    think. I don't really care that they are files or folders, I only want to
    know what they are, and if I can delete them. I see these all of the time
    when I am working on different computers, and I would feel better if I knew
    what they were. Each of them is not very big, but there are dozens, several
    dozen, of them and together they take time to be processed, and if they do
    nothing then there is no point in processing them.

    I want to sort on File Type, and these always float to the top, so I can
    simply grab huge chunks of folders that are named this way and delete them.

    In a related issue, when I use REGEDIT, I see literally hundreds of the same
    kinds of registry keys that are mostly empty.

    All of the characters are hexdecimal digits, 0-9 plus A-F, so they are
    generated by the file system somehow.
    Jeff Strickland, Jan 30, 2014
    #1
    1. Advertising

  2. Jeff Strickland

    Paul Guest

    Jeff Strickland wrote:
    > df84b7afba5b2c94f3194b06d0a5265b
    >
    >
    > I have several dozen of these kinds of files and folders, mostly folders
    > I think. I don't really care that they are files or folders, I only want
    > to know what they are, and if I can delete them. I see these all of the
    > time when I am working on different computers, and I would feel better
    > if I knew what they were. Each of them is not very big, but there are
    > dozens, several dozen, of them and together they take time to be
    > processed, and if they do nothing then there is no point in processing
    > them.
    >
    > I want to sort on File Type, and these always float to the top, so I can
    > simply grab huge chunks of folders that are named this way and delete them.
    >
    > In a related issue, when I use REGEDIT, I see literally hundreds of the
    > same kinds of registry keys that are mostly empty.
    >
    > All of the characters are hexdecimal digits, 0-9 plus A-F, so they are
    > generated by the file system somehow.


    I don't think there is much hope of tracing down where
    folders like that come from.

    I have folders with numeric names like that, of varying
    length. I don't have any 32 digits long. I have some shorter
    ones though.

    Service Packs, .NET updates, and other things, have a bad habit
    of randomly picking some disk drive, and plopping one of those
    at the top level. So we could hope that perhaps they
    would limit their "litter box" activity to just that area.

    Once in a great while, one of those folders will turn out to
    be important. You go to Add/Remove and attempt to uninstall
    something, and it will put up a dialog complaining that
    <random_hex_string> folder is missing. So in some cases,
    there is content there.

    You would have to ask the brain dead programmers, what
    they were thinking.

    *******

    The other kinds of strings, are called GUID. They're
    used in the Registry for indirection. By doubly
    dereferencing, it allows something to be changed,
    without the pointer to it needing to be changed.

    bob --> GUID
    carol --> GUID
    GUID --> some_other_thing <--- changing the definition here,
    changes all other references to
    this GUID. Double dereference so
    you don't have to chase down all
    the instances. You can change "bob"
    and "carol" at the same time.

    http://en.wikipedia.org/wiki/Globally_unique_identifier

    Those have a peculiar format. They're used, mainly
    because the odds are low of them colliding with one
    another. Some, when issued, are systematically generated
    (i.e. they're defined in groups). Lots more of them are
    purely randomly generated, for the property of not
    colliding with one another. This is the example in
    the Wikipedia article, of the text encoding.

    {21EC2020-3AEA-1069-A2DD-08002B30309D}

    That article also says, there is a binary encoding for
    those. It happens to be 128 bits or 16 bytes. In hex,
    it takes two characters to define a byte. So a hex
    string containing 128 bits of information just happens
    to be 32 digits long. Exactly the length
    of your folder example string above. So in
    fact, if that was a GUID at work, you could
    attempt conversion to the other representation,
    then search the registry for it.

    Using this tool, and the GUID converter at the bottom

    http://www.windowstricks.in/p/online-tools.html#guid

    this: df84b7afba5b2c94f3194b06d0a5265b

    becomes this: {afb784df-5bba-942c-f319-4b06d0a5265b}

    And you could look in the Registry for it. If you don't
    find either representation in the Registry, my guess
    is the folder was purely generated as a
    "kitty litter box" when they should have been
    using %temp%.

    Paul
    Paul, Jan 30, 2014
    #2
    1. Advertising

  3. Jeff Strickland

    Paul Guest

    Jeff Strickland wrote:
    >
    > "Paul" <> wrote in message
    > news:lcedso$id9$...
    >> Jeff Strickland wrote:
    >>> df84b7afba5b2c94f3194b06d0a5265b
    >>>
    >>>
    >>> I have several dozen of these kinds of files and folders, mostly
    >>> folders I think. I don't really care that they are files or folders,
    >>> I only want to know what they are, and if I can delete them. I see
    >>> these all of the time when I am working on different computers, and I
    >>> would feel better if I knew what they were. Each of them is not very
    >>> big, but there are dozens, several dozen, of them and together they
    >>> take time to be processed, and if they do nothing then there is no
    >>> point in processing them.
    >>>
    >>> I want to sort on File Type, and these always float to the top, so I
    >>> can simply grab huge chunks of folders that are named this way and
    >>> delete them.
    >>>
    >>> In a related issue, when I use REGEDIT, I see literally hundreds of
    >>> the same kinds of registry keys that are mostly empty.
    >>>
    >>> All of the characters are hexdecimal digits, 0-9 plus A-F, so they
    >>> are generated by the file system somehow.

    >>
    >> I don't think there is much hope of tracing down where
    >> folders like that come from.
    >>
    >> I have folders with numeric names like that, of varying
    >> length. I don't have any 32 digits long. I have some shorter
    >> ones though.
    >>
    >> Service Packs, .NET updates, and other things, have a bad habit
    >> of randomly picking some disk drive, and plopping one of those
    >> at the top level. So we could hope that perhaps they
    >> would limit their "litter box" activity to just that area.
    >>
    >> Once in a great while, one of those folders will turn out to
    >> be important. You go to Add/Remove and attempt to uninstall
    >> something, and it will put up a dialog complaining that
    >> <random_hex_string> folder is missing. So in some cases,
    >> there is content there.
    >>
    >> You would have to ask the brain dead programmers, what
    >> they were thinking.
    >>
    >> *******
    >>
    >> The other kinds of strings, are called GUID. They're
    >> used in the Registry for indirection. By doubly
    >> dereferencing, it allows something to be changed,
    >> without the pointer to it needing to be changed.
    >>
    >> bob --> GUID
    >> carol --> GUID
    >> GUID --> some_other_thing <--- changing the definition here,
    >> changes all other references to
    >> this GUID. Double dereference so
    >> you don't have to chase down all
    >> the instances. You can change "bob"
    >> and "carol" at the same time.
    >>
    >> http://en.wikipedia.org/wiki/Globally_unique_identifier
    >>
    >> Those have a peculiar format. They're used, mainly
    >> because the odds are low of them colliding with one
    >> another. Some, when issued, are systematically generated
    >> (i.e. they're defined in groups). Lots more of them are
    >> purely randomly generated, for the property of not
    >> colliding with one another. This is the example in
    >> the Wikipedia article, of the text encoding.
    >>
    >> {21EC2020-3AEA-1069-A2DD-08002B30309D}
    >>
    >> That article also says, there is a binary encoding for
    >> those. It happens to be 128 bits or 16 bytes. In hex,
    >> it takes two characters to define a byte. So a hex
    >> string containing 128 bits of information just happens
    >> to be 32 digits long. Exactly the length
    >> of your folder example string above. So in
    >> fact, if that was a GUID at work, you could
    >> attempt conversion to the other representation,
    >> then search the registry for it.
    >>
    >> Using this tool, and the GUID converter at the bottom
    >>
    >> http://www.windowstricks.in/p/online-tools.html#guid
    >>
    >> this: df84b7afba5b2c94f3194b06d0a5265b
    >>
    >> becomes this: {afb784df-5bba-942c-f319-4b06d0a5265b}
    >>
    >> And you could look in the Registry for it. If you don't
    >> find either representation in the Registry, my guess
    >> is the folder was purely generated as a
    >> "kitty litter box" when they should have been
    >> using %temp%.
    >>
    >> Paul
    >>
    >>
    >>
    >>

    >
    > I was once a technical writer for a company that developed a
    > TCP/IP-based factory automation system. You could bring up your factory
    > floor through a web browser and monitor what was going on, and affect
    > changes if you wanted. You could install a device that watched for
    > bearing failure, for example, and when the condition being monitored
    > became true, the device would automatically send an email to the repair
    > center so a technician could be dispatched. Very cool stuff...
    >
    > In any case, we discovered during testing that our installer was loading
    > up the computers with these hex-based files. Management said that it was
    > unacceptable to fill a customer's machine with all of these files, so
    > the software guys had to find the files/folders that came from out
    > processes and delete them. Of course, we could not go to the customer
    > site to find the files/folders, we had to find them programatically with
    > the installer and clean them out. I don't recall if the solution was to
    > remove them at the end of the install, or to remove them during a
    > subsequent upgrade-install.
    >
    > I never learned what they do or why they got deposited in the machines,
    > I only remember that somebody said that they were undesireable and it
    > was unacceptable for our stuff to make such a mess and then leave it.
    > Now, I find that I have the same mess and I was hoping I could go in
    > enmass and do a huge Delete, but I get from your description that this
    > would be dangerous.
    >


    I've run into cases, where a user attempts to use Add/Remove or
    Programs and Features, to remove a program. And a dialog pops
    up, asking for <random_number_path> folder, with the .msi file
    in it. There are certainly some folder contents, that are
    more dangerous to delete than others. If there was a single
    ..log file in the thing, I'd have little concern about deleting it.

    I don't even know, how you'd go about writing a script
    to find and delete stuff like that. If there wasn't a pointer
    in the Registry to it, there might be few other hints it is "detritus".

    Since the folder names don't even have the same length,
    we can't even use length as a trigger. While yours happens
    to be 32 characters long, and could be a GUID in binary
    form, I can easily find two other folder lengths on my
    disk here. So even length of the folder name, isn't
    enough to raise your suspicions. It would suggest
    there's more than one mechanism generating these.

    Paul
    Paul, Feb 1, 2014
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike
    Replies:
    5
    Views:
    1,741
    chuckcar
    Mar 28, 2008
  2. Beauregard T. Shagnasty

    Re: Do i need all these files and folders?

    Beauregard T. Shagnasty, Jul 9, 2010, in forum: Computer Support
    Replies:
    0
    Views:
    431
    Beauregard T. Shagnasty
    Jul 9, 2010
  3. Ctrl¤/Alt¤/Del¤

    Re: Do i need all these files and folders?

    Ctrl¤/Alt¤/Del¤, Jul 9, 2010, in forum: Computer Support
    Replies:
    3
    Views:
    494
    Peter Foldes
    Jul 9, 2010
  4. chuckcar

    Re: Do i need all these files and folders?

    chuckcar, Jul 9, 2010, in forum: Computer Support
    Replies:
    1
    Views:
    408
  5. Gordon

    Re: Do i need all these files and folders?

    Gordon, Jul 9, 2010, in forum: Computer Support
    Replies:
    0
    Views:
    392
    Gordon
    Jul 9, 2010
Loading...

Share This Page