LONGFI~1 ...win16 dir synch utils or XXCOPY16?

[omega]

Anyone remember any win16 directory synch programs they liked? I'm thinking
about testing that for my situation.

I need something that sees this kind of thing as equal:

\COMMON~1\MICROS~1\OFFICE~1\
\Common Files\Microsoft Shared\OfficeUpdate\

Or, more likely, the xxcopy16 utility, perhaps I should look into whether
there's a workable route using that? Since my synch needs are for 2+ gig
data, on a complex tree.

Directory one, it's a backup of my D drive, all normal, except that it's
some weeks old; and I want the updates from the more recent copy of my D
drive.

Directory two, it's the later copy of the D drive, but filled with smashed
file names. They were 8.3'd and all-capped by DOS Scandisk.

I had a physical disk crash. Before its final wheeze, it spent a few days
on its death bed. Bad sectors outbreak everywhere. At one of the earlier
hours of its dying, a DOS scandisk did enough emergency patching to allow
a boot into Windows, where I then xxcopy'ed the drive. Scandisk truncated
a lot of the filenames to 8.3 at that point, but not deleted much. (It was
later on that it gleefully amputated everything in sight.)

For the record, there is not a system / soft problem that caused this state
of affairs. When I removed the dead disk, it sounded like when you shake a
dead lightbulb, with broken rattling inside. New drive, and all FAT is fine.
(W98/vfat, sfn-lfn back to normal entries, & scandisk no longer feeling a
need to slice and dice.)

My need is to see what I can get out of my copy of D that has the 8.3
filenames. What changes I can keep, when I compare it against the earlier
backup. And the way I see to approach this is by using something that cannot
see long file names. Just to give me a list at least. How to proceed after
the list, I haven't thought that far into it (figure wait until I'm seeing
what tools might be available)...

 

[dszady]

Anyone remember any win16 directory synch programs they liked? I'm thinking
about testing that for my situation.

I need something that sees this kind of thing as equal:

\COMMON~1\MICROS~1\OFFICE~1\
\Common Files\Microsoft Shared\OfficeUpdate\

Or, more likely, the xxcopy16 utility, perhaps I should look into whether
there's a workable route using that? Since my synch needs are for 2+ gig
data, on a complex tree.

Directory one, it's a backup of my D drive, all normal, except that it's
some weeks old; and I want the updates from the more recent copy of my D
drive.

Directory two, it's the later copy of the D drive, but filled with smashed
file names. They were 8.3'd and all-capped by DOS Scandisk.

I had a physical disk crash. Before its final wheeze, it spent a few days
on its death bed. Bad sectors outbreak everywhere. At one of the earlier
hours of its dying, a DOS scandisk did enough emergency patching to allow
a boot into Windows, where I then xxcopy'ed the drive. Scandisk truncated
a lot of the filenames to 8.3 at that point, but not deleted much. (It was
later on that it gleefully amputated everything in sight.)

For the record, there is not a system / soft problem that caused this state
of affairs. When I removed the dead disk, it sounded like when you shake a
dead lightbulb, with broken rattling inside. New drive, and all FAT is fine.
(W98/vfat, sfn-lfn back to normal entries, & scandisk no longer feeling a
need to slice and dice.)

My need is to see what I can get out of my copy of D that has the 8.3
filenames. What changes I can keep, when I compare it against the earlier
backup. And the way I see to approach this is by using something that cannot
see long file names. Just to give me a list at least. How to proceed after
the list, I haven't thought that far into it (figure wait until I'm seeing
what tools might be available)...

Don't you have to have the right ver. of DOS for 16bit files?
I have XCOPY.exe 16bit DOS 6.22

 

[omega]

Don't you have to have the right ver. of DOS for 16bit files?
I have XCOPY.exe 16bit DOS 6.22

Hiya, dszady. (Happy 2004!)

I'd rather not make a DOS6 system partition - would like to work in a normal
Windows environment. Just now I just tried out DOS6's xcopy.exe in a command
window. Got the message, "Incorrect DOS version." I don't recall the steps
for workarounds such as how to lie about one's DOS version, or setting up an
alternate command processor. I'm holding out instead for getting XXCOPY16 to
work for my need...

When I told XXCOPY16 to copy a directory with these files:

this is a long name.txt
THISIS~1.TXT

It copied them out to files with these names:

THISIS~2.TXT
THISIS~1.TXT

That shows me it can't see long names, which is I believe to be what I
need. I also remember that xxcopy works to compare files, giving a list
of differences. I'd have to look up the switches. I'm hoping Kan Yabumoto
might appear en scene, and hold my hand.

If I can get an output list from XXCOPY16, then I think my remaining steps
will be manual, to do renames of my newer files into their long names, and
I don't mind that. It's the initial hunting down for differences manually
which I want to avoid, since it involves 40+ thousand files in 5+ thousand
sub-directories, for each of the two folders to be compared.

 

[Kan Yabumoto]

Anyone remember any win16 directory synch programs they liked? I'm thinking
about testing that for my situation.

I need something that sees this kind of thing as equal:

\COMMON~1\MICROS~1\OFFICE~1\
\Common Files\Microsoft Shared\OfficeUpdate\

Or, more likely, the xxcopy16 utility, perhaps I should look into whether
there's a workable route using that? Since my synch needs are for 2+ gig
data, on a complex tree.

My need is to see what I can get out of my copy of D that has the 8.3
filenames. What changes I can keep, when I compare it against the earlier
backup. And the way I see to approach this is by using something that cannot
see long file names. Just to give me a list at least. How to proceed after
the list, I haven't thought that far into it (figure wait until I'm seeing
what tools might be available)...

Before giving you my recommendation of some repair work using XXCOPY,
let me make sure my assumptions are correct.

1. You have working Win98 with a very similar setup to the
original (on the older, now broken disk).

2. You have a set of recovered copy of major directories which used to be
on the old disk. The contents of these files are believed to be
perfect and the only problem is that the filenames are in the 8.3 format.

3. You can say for sure that all the files in the 8.3 format in the
recovered directories can be safely written to their corresponding
files in the working directories.

Here. let me use concrete names to make sure you understand
what I wrote in item 3.

Say, your working directory contains:

D:\Common Files\Microsoft Shared\OfficeUpdate\letter_to_my_boss.doc

and you copied recovered directory into D:\RESTORED\

D:\RESTORED\COMMON~1\MICROS~1\OFFICE~1\LETTER~1.DOC
D:\RESTORED\COMMON~1\MICROS~1\OFFICE~1\OLDFIL~1.DOC

and, you are sure that you do not mind overwriting the existing file
in the working directory (letter_to_my_boss.doc) by its counterpart
(LETTER~1.DOC) because the one in the working directory has exactly
the same SFN. I suppose you also have orphaned files in the recovered
directory whose counterpart cannot be found in the working directory.

Anyway, XXCOPY can attach an LFN to an SFN-only file by matching the pair
using the common SFN name.

Since the recovered data is probably important, I would go with
safer route by first making a complete copy of the recovered data
so that if this recovery effort does not work, you can try other
methods.

Here's the step I recommend:

XXCOPY \RESTORED\ \RESTORE2\ /BACKUP // make a duplicate
XXCOPY "\Common Files\" \RESTORE2\COMMON~1\ /S/NL // attach LFN

Note that the /NL operation does not transfer file contents,
timestamps, or any other attributes. It assigns the proper
LFN to the matching files in the destination (the pair is
made by the SFN). After this operation, *ALL* files with the
common SFN in the destination directory will be the same as
those in the source. Files in the destination that does not
have matched name in the source will remain the same.

Now, you want to merge the \RESTORE2\ (after the /NL operation)
into the working directory. Again, let us use a cautionary measure.

XXCOPY "\Common Files\" "\Common File.bak\" /BACKUP // just in case

Finally, let us merge the two:

XXCOPY \RESTORE2\COMMON~1\ "\Common Files\" /KS/H/E/R/Y // merge them

As to orphaned files (the files that was recovered in SFN-only and
its counterpart cannot be found in the working directory), they, will
remain in the 8.3 name only. You have to use your own (brain's) memory
to rename them as best you can.

If this does not work, you have a backup copy at

\Common Files.bak\
\RESTORED\

============================

If you are somewhat mystified by what /NL does, you can do the
following experiment and observe the effect:

XXCOPY "\common files\" \xxtemp\ /s/n/qf:20

The /N switch handles everything in 8.3 name. This simulates
Karen's case where the LFNs were lost in the copying process
but the the actual files are recovered using the SFN.
The /QF:20 switch stops the operation after 20 files are
copied (to keep this experiment small).

Use the DIR command and check the names in the \xxtemp\.

XXCOPY "\common files\" \xxtemp\ /S/NL

Again, check the contents in the \xxtemp\ directory. The
original LFN is attached to the files.

Incidentally, notice that I did not mention XXCOPY16.EXE here.
That's because XXCOPY.EXE (the 32-bit version) is the only
one which can handle any operation that involves the LFN.

If you have more questions about this, please consider becoming
a member of the XXCOPY discussion group and post your question.

http://groups.yahoo.com/group/xxcopy/

Good luck
Kan Yabumoto
The author of XXCopy

 

[ms]

snip

I had a physical disk crash. Before its final wheeze, it spent a few days
on its death bed. Bad sectors outbreak everywhere. At one of the earlier
hours of its dying, a DOS scandisk did enough emergency patching to allow
a boot into Windows, where I then xxcopy'ed the drive. Scandisk truncated
a lot of the filenames to 8.3 at that point, but not deleted much. (It was
later on that it gleefully amputated everything in sight.)

For the record, there is not a system / soft problem that caused this state
of affairs. When I removed the dead disk, it sounded like when you shake a
dead lightbulb, with broken rattling inside.

snip
Hello Karen:
I can't help with your question, but the hard disk crash- what brand was
it and how old (how much use) ?

The reason I ask is that Ive been running a Western Digital HD daily
since 1997, about 26000 hours so far, seems to be fine as a second,
storage drive. I'm wondering if I can trust it.

Mike Sa

 

[dszady]

Hiya, dszady. (Happy 2004!)

I'd rather not make a DOS6 system partition - would like to work in a normal
Windows environment. Just now I just tried out DOS6's xcopy.exe in a command
window. Got the message, "Incorrect DOS version." I don't recall the steps
for workarounds such as how to lie about one's DOS version, or setting up an
alternate command processor. I'm holding out instead for getting XXCOPY16 to
work for my need...

When I told XXCOPY16 to copy a directory with these files:

this is a long name.txt
THISIS~1.TXT

It copied them out to files with these names:

THISIS~2.TXT
THISIS~1.TXT

That shows me it can't see long names, which is I believe to be what I
need. I also remember that xxcopy works to compare files, giving a list
of differences. I'd have to look up the switches. I'm hoping Kan Yabumoto
might appear en scene, and hold my hand.

If I can get an output list from XXCOPY16, then I think my remaining steps
will be manual, to do renames of my newer files into their long names, and
I don't mind that. It's the initial hunting down for differences manually
which I want to avoid, since it involves 40+ thousand files in 5+ thousand
sub-directories, for each of the two folders to be compared.

Happy New Year to you too, Karen!
I think the difference is in command.com and you're right, not worth the
bother. 5000 directories? Oh my!

 

[John Fitzsimons]

The reason I ask is that Ive been running a Western Digital HD daily
since 1997, about 26000 hours so far, seems to be fine as a second,
storage drive. I'm wondering if I can trust it.

Umm. That's got me curious. Was 26000 a guess or have you installed a
program to record how long your system has been running ?

Regards, John.

 

[Cousin Stanley]

| Umm. That's got me curious. Was 26000 a guess
| or have you installed a program to record
| how long your system has been running ?

John ....

I'm guessing the 'puter in question
was only on half the time ....

python year_hours.py

Enter Begin Year .... 1997
Enter End Year .... 2003

Total Hours ......... 52560

 

[ms]

| Umm. That's got me curious. Was 26000 a guess
| or have you installed a program to record
| how long your system has been running ?

John ....

I'm guessing the 'puter in question
was only on half the time ....

python year_hours.py

Enter Begin Year .... 1997
Enter End Year .... 2003

Total Hours ......... 52560

Then divide by 2 as I shut down at 5PM, boot up about 4 AM.

26280 pretty close to my estimate of 26000 hours.

I've had very good luck so far with Western Digital.

Mike Sa

 

[ms]

Umm. That's got me curious. Was 26000 a guess or have you installed a
program to record how long your system has been running ?

Regards, John.

12 hours daily X 360 days X 6 years to get approximate hours.

Mike Sa

 

[omega]

TimeLapseWarn: Thread Resurrect

I can't help with your question, but the hard disk crash- what brand was
it and how old (how much use) ?

The disk that just died was an Hitachi, came with the IBM notebook, active
life was about three and a half years.

The reason I ask is that Ive been running a Western Digital HD daily
since 1997, about 26000 hours so far, seems to be fine as a second,
storage drive. I'm wondering if I can trust it.

In the period when I was running desktops, and regularly buying hard drives,
I most always chose Maxtors. I remember that, somewhere during the period
around 97-99, when I was reading comp.sys.ibm.pc.hardware.storage, it was
Western Digital that was having a repeated series of problems, with a
repeated major product recalls. Their customer service had a good rep, but
they were having a notably bad run as far as sending out bad hdds. Maxtor
wasn't showing this pattern, and also they had reasonably priced drives.

Then, as my luck had it, in year 2000, I had a succession of three (!)
Maxtors crash. There were two drives which were the same make and model,
their serials only digits apart, meaning like born in the same litter.
One was the primary of my active drives, and one was my backup drive.
At about six months of age, they both died. Within weeks of each other.

And I had not been adequately organized during that (hectic) period of my
life to be left with much beyond large loss of data. The type of crash was
hardcore, have to look up the language, but ~memory says something like the
controller board. No disk recovery software in the world could get beyond the
physical problem, and the only choice would have been to send them to one of
the fanciest clean rooms to replace the parts, then pray (and cost would have
run $2-5k).

The third Maxtor demise came in later. I put it off for a long time, but
eventually decided to get data from a drive that had been in my computer
about a year earlier that the two dead Maxtors. It was formatted, but disk
recovery software still let me start the process of getting the data. Only,
partway through the data retrieval process, it had a head crash. Makes for my
count of three in a row.

Yet, I don't blame Maxtor. I am convinced that what determines disk crashes
is a Murphy's law. Disk crashes will specifically schedule their arrival
according to when it is that you are least backed up. Even this recent crash
of mine, the 3-4 week period that had transpired since my last backup, it was
the longest lapse of mine in quite a while. (If not for XXCopy coming to the
rescue to repair my LFNs, it would have been a hard bummer for me.)

Or, one story of the Murphy timing. A friend of mine, fairly new to
computers, I'd talked her into using second HDD as backup system. From
the point where she agreed to that strategy, to the point where it was
implemented, that was process of weeks. The weeks went slowly, while I
guided her though researching and ordering the drive, and then same for
the HDD cloning software. Eventually UPS delivered everything, and we had
an appointment on a Thursday to install the new drive and do the backup.

I ended changing the Thursday appointment to a Sunday (had to go out drinking
or something, forget now). Then, Sunday morning, three hours before I was
due at her house, I got an email from her. Sent from Kinko's. That morning,
her drive let off with a great wailing screech, then keeled over, and died.
(Head crash.) Just three hours (!) before the scheduled backup.

Age of drive, about six months. Brand, IBM. Yet I don't consider these as
pertinent factors. It was Murphy timing alone that determined its crash...

Re-quote,

The reason I ask is that Ive been running a Western Digital HD daily
since 1997, about 26000 hours so far, seems to be fine as a second,
storage drive. I'm wondering if I can trust it.

This is a fantastic run. It reminds me of my 250 meg Samsung, which clocked
more tens of thousands of hours active use than I can even count, and is
still alive today. While I no longer run it, I honor it too much to ever be
able tothrow it away.

I note that there is supposed to be some special way the numbers work, where
likelihood of life-end is highest in the first year, and then again in the
fifth year, or something or something (I don't want to bother with looking it
up, MTBF and all).... Just again, I do not see it as playing the numbers.

Instead: to back up, often! HIGHEST PRIORITY.

BackupBackupBackupBackupBackup. Oooops. Yep, at the moment I am again lapse
in the routine! Not backed up in a couple of weeks. So I'm scrawling those
words across my own screen, in bright red.