T##### files in OS/2 boot directory - OS2

This is a discussion on T##### files in OS/2 boot directory - OS2 ; As i get to service older boxes of OS/2 I've noticed some of them have quite a few files in the boot directory that are named T#######. As a command line guy, I almost never use the OS/2 Desktop Connections ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: T##### files in OS/2 boot directory

  1. T##### files in OS/2 boot directory

    As i get to service older boxes of OS/2 I've noticed some of them have quite a
    few files in the boot directory that are named T#######. As a command line
    guy, I almost never use the OS/2 Desktop Connections folder to drill down and
    see its view of a drive. I looked into these with File Freedom and noticed
    they almost all seemed to contain only a few nested subdirectories and no
    'files' as such. Focusing first on a directory 'OS!2 System' thence into
    'Templates' thence into 'Folder1' So I chose to try this in the Connections
    object.

    Interesting! These all show up there as 'Desktop' which drill down into the
    appropriate nest objects of name. Where do these come from? Are they perhaps
    the result of a system which cannot boot to the desktop and boots to a
    temporary desktop?

    More important, how do we get rid of them? So I experimented with this on a
    box with a complete tape backup of the system. I first chose one of these
    simplest three step directory T####### objects. I used File Freedom to simply
    hand delete the lowest level item first .. moving to the top T####### item in
    the root directory, then deleting that. I then used Unimaint to see what that
    had done to the desktop. Yep, dirty items for everything deleted. But when
    done it was gone from the box.

    But then I hit an issue where even though a Folder1 didn't show it was
    populated, it apparently had all of the OS/2 Templates in it. After the hand
    File Freedom delete and a try to move up to the Templates item, the system
    produced all kinds of errors for what were seemed 'actual templates'. Unimaint
    did clean this up and I got through removing this one, checking each time on
    the fact that the actual items and templates in the folder in the normal
    Desktop were still there and remained there even with the 'erasement' of
    whatever was in the strange little desktop T####### file.

    Then I hit one of these that Unimaint couldn't seem to fix. So I went to
    Checkini /c to see what it would produce. It produced a complete new folder on
    the main desktop with a complete pane of actual Templates in it! As I looked
    at this closely, all of these templates appeared to be shadows, not originals,
    but yet could not be traced to any 'originals' with an OS/2 desktop object
    property trace click. Further, there was no delete option for any of these
    template shadows in the property choices!

    However, the actual new Checkini Folder on the Desktop did still have a Delete
    option. I punched it and the folder vanished! After which Unimaint was able
    to clean up each and every item that was in it with a repair run.

    And for research purposes, if I look at this in the Connections folder step by
    step during all this process, I'll see the items vanishing from that graphics
    display mode there as well. Well I thought that this was all that was involved
    but little did I know I could be very wrong.

    Further, I found that if I'd perform a Unimaint cleanup run after each and
    every discrete File Freedom erase step, I didn't see this strange major
    corruption mess as well. Things seemed to go pretty well at this until I hit a
    big one. On one SCSI box for which I had a complete cloned hard drive image
    with DFSEE I suddenly hit far worse.

    This one actually soemhow erased the entire actual file complement, but not the
    sub directories, for the whole C: boot partition in the 'cleanup'! Shocked, I
    changed the drive pin assignment on it. I attached it to the cloned complete
    drive behind it. I then used XCOPY with a carefully chosen /H/O/T/E/R/V and no
    /S subdirectory choice to restore the C:\ root files. The drive re-booted just
    fine after the DFSEE dirty byte hand set and the T######## item was gone on it.
    I was able to both Unimaint and Checkini it for what has proved to be a full
    recovery.

    OK .. now I'm down to two boxes which show as the first step in File Freedom
    for the last and most interesting variation of this T####### issue just one
    such item. But these have in them:

    \Connections
    \OS!2 System
    \Programs

    And guess what? In that \Connections folder in this ghost T####### desktop,
    there are no files shown in the root directory. But guess what else? If I
    drill down into the sub-directories, yes, all the FILES in many, but not all,
    of the subdirectories, are still showing as items in the \Connections folder
    view! But are nowhere to be seen in the File Freedom view. So now I seem to
    know how this all blew up on the box that had all the root directory files
    erased before.

    What are these T###### items? How can I finish cleaning up these two boxes
    without a real mess on my hands?

    Any help here?



    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  2. Re: T##### files in OS/2 boot directory

    On Sun, 7 Sep 2008 14:22:46 UTC, Mike Luther
    wrote:

    > What are these T###### items? How can I finish cleaning up these two boxes
    > without a real mess on my hands?
    >
    > Any help here?


    I think you need to be a little more specific, about exactly what you
    are seeing. There are many files that might be what you are refering
    to.

    As a WAG, I would guess that you have one of the system trace tools
    active, and what you are seeing are trace files, of some sort.

    --
    From the eComStation 2.0 RC2 of Doug Bissett
    dougb007 at telus dot net
    (Please make the obvious changes, to e-mail me)


  3. Re: T##### files in OS/2 boot directory

    Thanks Doug

    Doug Bissett wrote:
    > I think you need to be a little more specific, about exactly what you
    > are seeing. There are many files that might be what you are refering
    > to.
    >


    The volume label in drive C is ZL3003-C.
    The Volume Serial Number is E88F414.
    Directory of C:\

    4-27-03 7:07p 857 T0107001

    Thence cd t0107001 which has in it:


    The volume label in drive C is ZL3003-C.
    The Volume Serial Number is E88F414.
    Directory of C:\t0107001

    1-21-04 4:18a 0 .
    1-21-04 4:18a 0 ..
    4-27-03 7:07p 4520 Connections
    4-27-03 7:07p 8561 OS!2 System
    4-27-03 7:07p 4525 Programs

    Thence cd Connections which has in it:

    The volume label in drive C is ZL3003-C.
    The Volume Serial Number is E88F414.
    Directory of C:\t0107001\Connections

    1-21-04 4:18a 0 .
    1-21-04 4:18a 0 ..
    12-12-98 3:37p 608 Drives
    12-12-98 3:37p 543 Network
    5-03-03 10:28p 8564 Printers
    4-27-03 7:07p 409 Web Sites

    Thence cd Drives which has in it:

    The volume label in drive C is ZL3003-C.
    The Volume Serial Number is E88F414.
    Directory of C:\t0107001\Connections\Drives

    1-21-04 4:18a 0 .
    1-21-04 4:18a 0 ..

    But not really!!!

    If I look in the Connections folder from the desktop and drill down into
    the C:\ drive the same way in it. Surprise!!

    There are a complete visual OBJECT display of every file in the whole
    C:\ root directory and every subdirectory and every file in every
    subdirectory!

    Then .. if per what I seem to have experienced on this other box with
    something similar to this .. I attempt to delete the Drives directory
    ... It will actually visually do this directly. But then a few seconds
    later, I will see warning after warning about this or that. For what
    are seemingly objects which can't be deleted. But if objects of files,
    they ARE deleted!


    > As a WAG, I would guess that you have one of the system trace tools
    > active, and what you are seeing are trace files, of some sort.


    Well .. FFST isn't loaded. And as you can tell from the dates above,
    this apparently erupted in 04-27-03 yet the directory and other data
    shows the dates of even 01-21-04 here.

    Again, in this case I recall that years ago, I've had a few failure to
    boot instances with this box. Which booted to a temporary desktop.
    From which at least one way to recover whatever was to simply go back
    to the Unimaint restore tool. I've also used, at times, the official
    OS/2 Desktop restore from archives as well if needed. But other than
    this sort of thing I have no idea at all how this is produced.

    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  4. Re: T##### files in OS/2 boot directory

    On Sun, 7 Sep 2008 16:18:01 UTC, Mike Luther
    wrote:

    > Thanks Doug
    >
    > Doug Bissett wrote:
    > > I think you need to be a little more specific, about exactly what you
    > > are seeing. There are many files that might be what you are refering
    > > to.
    > >

    >
    > The volume label in drive C is ZL3003-C.
    > The Volume Serial Number is E88F414.
    > Directory of C:\
    >
    > 4-27-03 7:07p
    857 T0107001
    >
    > Thence cd t0107001 which has in it:
    >
    >
    > The volume label in drive C is ZL3003-C.
    > The Volume Serial Number is E88F414.
    > Directory of C:\t0107001
    >
    > 1-21-04 4:18a
    0 .
    > 1-21-04 4:18a
    0 ..
    > 4-27-03 7:07p
    4520 Connections
    > 4-27-03 7:07p
    8561 OS!2 System
    > 4-27-03 7:07p
    4525 Programs
    >
    > Thence cd Connections which has in it:
    >
    > The volume label in drive C is ZL3003-C.
    > The Volume Serial Number is E88F414.
    > Directory of C:\t0107001\Connections
    >
    > 1-21-04 4:18a
    0 .
    > 1-21-04 4:18a
    0 ..
    > 12-12-98 3:37p 608 Drives
    > 12-12-98 3:37p 543 Network
    > 5-03-03 10:28p 8564 Printers
    > 4-27-03 7:07p 409 Web Sites
    >
    > Thence cd Drives which has in it:
    >
    > The volume label in drive C is ZL3003-C.
    > The Volume Serial Number is E88F414.
    > Directory of C:\t0107001\Connections\Drives
    >
    > 1-21-04 4:18a 0 .
    > 1-21-04 4:18a 0 ..
    >
    > But not really!!!
    >
    > If I look in the Connections folder from the desktop and drill down into
    > the C:\ drive the same way in it. Surprise!!
    >
    > There are a complete visual OBJECT display of every file in the whole
    > C:\ root directory and every subdirectory and every file in every
    > subdirectory!
    >
    > Then .. if per what I seem to have experienced on this other box with
    > something similar to this .. I attempt to delete the Drives directory
    > .. It will actually visually do this directly. But then a few seconds
    > later, I will see warning after warning about this or that. For what
    > are seemingly objects which can't be deleted. But if objects of files,
    > they ARE deleted!
    >
    >
    > > As a WAG, I would guess that you have one of the system trace tools
    > > active, and what you are seeing are trace files, of some sort.

    >
    > Well .. FFST isn't loaded. And as you can tell from the dates above,
    > this apparently erupted in 04-27-03 yet the directory and other data
    > shows the dates of even 01-21-04 here.
    >
    > Again, in this case I recall that years ago, I've had a few failure to
    > boot instances with this box. Which booted to a temporary desktop.
    > From which at least one way to recover whatever was to simply go back
    > to the Unimaint restore tool. I've also used, at times, the official
    > OS/2 Desktop restore from archives as well if needed. But other than
    > this sort of thing I have no idea at all how this is produced.

    Hmmm. Strange. I have never seen, or even heard of, anything like
    that. I don't think that happens when a temporary desktop is created
    (but it has been years since I saw that happen, so I may be forgetting
    something. The only other thing, that I can think of, is that the
    root of the boot drive, will be used for temporary files, if there is
    no valid entry in CONFIG.SYS for:
    SET TEMP=x:\TEMP
    SET TMP=x:\TEMP
    SET TMPDIR=x:\TEMP
    (the last one shows up in some versions of eCS, but I don't know of
    anything that actually uses it). Of course, you should be able to
    delete the directory, and files, if they are TEMP files, and not in
    use. If the files are templates, they may actually be in use, when the
    WPS is loaded, which would make it difficult to remove them. I think I
    would try to copy them to some removable media (or even move them to
    removable media), then remove the media (you may need to shut down to
    be able to do that), then boot to a command line, and remove the
    directory, and files (if you didn't move them). Of course, a good
    backup might be a good idea, in case that doesn't work.

    --
    From the eComStation 2.0 RC2 of Doug Bissett
    dougb007 at telus dot net
    (Please make the obvious changes, to e-mail me)


  5. Re: T##### files in OS/2 boot directory

    On 09/08/08 08:07 pm, Doug Bissett wrote:
    > SET TMPDIR=x:\TEMP
    > (the last one shows up in some versions of eCS, but I don't know of
    > anything that actually uses it).


    *nix configure scripts and other build systems use %TMPDIR%
    Dave

  6. Re: T##### files in OS/2 boot directory

    Mike Luther wrote:
    > Thanks Doug
    >
    > Doug Bissett wrote:
    >
    >> I think you need to be a little more specific, about exactly what you
    >> are seeing. There are many files that might be what you are refering to.

    >
    > The volume label in drive C is ZL3003-C.
    > The Volume Serial Number is E88F414.
    > Directory of C:\
    >
    > 4-27-03 7:07p
    857 T0107001
    >
    > Thence cd t0107001 which has in it:
    >
    >
    > The volume label in drive C is ZL3003-C.
    > The Volume Serial Number is E88F414.
    > Directory of C:\t0107001
    >
    > 1-21-04 4:18a
    0 .
    > 1-21-04 4:18a
    0 ..
    > 4-27-03 7:07p
    4520 Connections
    > 4-27-03 7:07p
    8561 OS!2 System
    > 4-27-03 7:07p
    4525 Programs

    Any chance this is a temporary / emergency desktop? Are you booting
    normally?

    --
    [Reverse the parts of the e-mail address to reply.]

  7. Re: T##### files in OS/2 boot directory

    Thanks Marty

    Marty wrote:

    >
    > Any chance this is a temporary / emergency desktop? Are you booting
    > normally?
    >


    I speculated that it was in the original post. It has been a long time since I
    have ever seen OS/2 not able to boot normally through to the desktop. It then
    prints an alert message that it cannot and is booting to a 'temporary' desktop.
    From there, typically you see a totally blank solid color screen. The
    'normal' recovery from this is to either boot to a command line via the F1 key
    at the OS/2 boot blob method, or from a utility disk boot. In all cases for me
    this has been an F1 key recovery or the floppy diskette utility boot, and not a
    CD-ROM boot.

    I either recover the desktop from a Unimaint recovery choice, or the formal
    OS/2 recovery choice from the F1 OS/2 utility boot choice screen.

    It's been years since I have seen this. But I wonder now that I've seen these
    T####### 'desktop' directory entries in the root directory, if maybe this is
    part of that process? As initially stated, I'd wondered about these for years,
    but only now had happened to see these as objects in the Connections folder.

    Again, the dates on these, at a minimum, go back to the 2003 or 2004 era for
    the most recent dates in the system I see. Many went back to 1998 or so! I've
    now seen these in more than a dozen OS/2 MCP2 level boxes. Yet some of my own
    don't have any of this at all!

    \ ?
    (!)
    @ @

    Puppy is wondering!


    --


    --> Sleep well; OS2's still awake!

    Mike Luther

  8. Re: T##### files in OS/2 boot directory

    On Tue, 9 Sep 2008 14:59:00 UTC, Dave Yeo wrote:

    > On 09/08/08 08:07 pm, Doug Bissett wrote:
    > > SET TMPDIR=x:\TEMP
    > > (the last one shows up in some versions of eCS, but I don't know of
    > > anything that actually uses it).

    >
    > *nix configure scripts and other build systems use %TMPDIR%


    ... and ClamAV


    --
    Allan.

    It is better to close your mouth, and look like a fool,
    than to open it, and remove all doubt.

  9. Re: T##### files in OS/2 boot directory

    Doug Bissett schrieb:
    > SET TEMP=x:\TEMP
    > SET TMP=x:\TEMP
    > SET TMPDIR=x:\TEMP
    > (the last one shows up in some versions of eCS, but I don't know of
    > anything that actually uses it).

    The Samba Server for eCS uses that one and crashes in case it is not set.

    Kind regards,
    Herwig