• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

XCOPY not preserving timestamp for directories.

Started by ppgrainbow, 2010.08.02, 06:13:44

Previous topic - Next topic

ppgrainbow

I need a bit of help here.

I recently created a larger 4 GB hard disk image under Virtual PC in a attempt to replace the 2 GB hard disk image. I entered this command at the command prompt to copy the contents of the old hard disk image to the newer one:

xcopy /h /o /t /s /e /r /v

When the XCOPY cloning process gets finished, it does NOT preserve the timestamp for directories from the original hard disk.

For example, the C:\OS2 directory had the 29 July 2009 time stamp on the old hard disk image and the newer one found on drive D: had the date stamp of 1 August 2008!

I tried numerous utilities (Clonezilla, DFSee, etc.) to clone the data from the old hard disk image to the newer one and OS/2 wouldn't even boot.

Are there any freeware or shareware replacements for XCOPY that will support the preservation of keeping the existing date and time creation of the directory from the old hard disk?

Thanks! :)

(By the way, I'll get back to my other forum thread when someone finds a solution to this problem.)

warpcafe

Hi,

ehh... I am not sure if there is the NEED for having timestamps of directories being kept.
I doubt OS/2 refuses to boot just because a timestamp doesn't match.

I rather guess there is something else fishy about the way you try to clone the disk / partition.
You said you tried DFSee but it didn't help. Well, this is highly questionable ;) sine when it comes to such things, DFSee is one of the very few programs that you can trust for doing things correctly. Perhaps there is some misunderstanding by you on the approach or even a hardware defect somewhere...

Did you try creating a bootable partition on the new harddisk (with the same file system and preferrably the same size to rule out any possible errors) and then "clone objects" from old partition? Perhaps someone else can add more hints here? You may also want to post a request for help into the DFSee user forum at http://groups.yahoo.com/group/dfsee-support ?

Regarding the timestamp preservation question... I have no idea. I am not sure if FC/2 can do this... and I can't check at the moment because I am working on a company machine running windows and the VirtualBox install is somehow broken so I need to fix that before being able to run OS/2... will let you know once I am back "online".

HTH,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

ppgrainbow

Quote from: warpcafe on 2010.08.02, 10:46:43
Hi,

ehh... I am not sure if there is the NEED for having timestamps of directories being kept.
I doubt OS/2 refuses to boot just because a timestamp doesn't match.

I rather guess there is something else fishy about the way you try to clone the disk / partition.
You said you tried DFSee but it didn't help. Well, this is highly questionable ;) sine when it comes to such things, DFSee is one of the very few programs that you can trust for doing things correctly. Perhaps there is some misunderstanding by you on the approach or even a hardware defect somewhere...

Did you try creating a bootable partition on the new harddisk (with the same file system and preferrably the same size to rule out any possible errors) and then "clone objects" from old partition? Perhaps someone else can add more hints here? You may also want to post a request for help into the DFSee user forum at http://groups.yahoo.com/group/dfsee-support ?

Regarding the timestamp preservation question... I have no idea. I am not sure if FC/2 can do this... and I can't check at the moment because I am working on a company machine running windows and the VirtualBox install is somehow broken so I need to fix that before being able to run OS/2... will let you know once I am back "online".

HTH,
Thomas

Thanks for the input. I managed to solve the problem most of the way by creating a Windows NT 4.0 VM and installing HPFS drivers and using the XXCOPY command to copy all of the data from the smaller hard disk image to the larger one.

However, I don't want to delete the 2 GB hard disk image until everything has be corrected. When I tried to boot up the 4 GB hard disk image, I wound up with a error message referencing to OS2.INI and OS2SYS.INI as well as a corrupt desktop.

As for using DFSee, I don't know if cloning the objects from the old partition is going to help or not. Because without any hints on how to properly clone the old hard disk image to the larger one, I'm afraid that I'm not gonna get any help.

rudi

Quote from: warpcafe on 2010.08.02, 10:46:43
I am not sure if FC/2 can do this...

It can. However, it will not preserve the timestamps of the "." and ".." entries.
Keeping those is only possible when cloning...

ppgrainbow

Quote from: rudi on 2010.08.02, 13:09:58
Quote from: warpcafe on 2010.08.02, 10:46:43
I am not sure if FC/2 can do this...

It can. However, it will not preserve the timestamps of the "." and ".." entries.
Keeping those is only possible when cloning...


I tried very hard to clone the hard disk, but it still wouldn't boot at all. All I'm getting is a blinking cursor when booting from the newly cloned drive. The old 2 GB hard disk image still works though.

How can I fix this? I'm stuck here.

Also, is not being able to preserve the timestamps of the "." and ".." a design limitation of the OS/2 operating system?

DougB

First, be aware that XCOPY does have known problems, but I doubt if that is what is causing your problem. It also doesn't matter if the folder dates get changed.

Try using the SYSINSTX command, to the new drive, from the 2 GB drive boot:
C:\OS2\INSTALL\BOOTDISK\SYSINSTX.COM x:
(x: is the new drive letter).

If that won't work, I would suggest simply adding a new drive, and use that for data and programs (that is a recommended way of doing it anyway, it is much easier to update to a newer version of the OS, if there is nothing except the OS on the drive that is being updated).

ppgrainbow

Quote from: DougB on 2010.08.02, 20:26:08
First, be aware that XCOPY does have known problems, but I doubt if that is what is causing your problem. It also doesn't matter if the folder dates get changed.

Try using the SYSINSTX command, to the new drive, from the 2 GB drive boot:
C:\OS2\INSTALL\BOOTDISK\SYSINSTX.COM x:
(x: is the new drive letter).

If that won't work, I would suggest simply adding a new drive, and use that for data and programs (that is a recommended way of doing it anyway, it is much easier to update to a newer version of the OS, if there is nothing except the OS on the drive that is being updated).

Thanks!

Here's what I did. I had to use the utility called VHD Resizer to resize the hard disk from 2 GB to 4 GB. Then, I used a utility called DFSFree to resize the partition in the newly cloned drive.

When that was finished, I had to use the utility diskettes (installation diskette and three disks) and modify the installation disk and disk 3.

In the installation diskette, I had to modify the config.sys file on line 8 to include the line:

ifs=hpfs.ifs /cache:64 /crecl:4

Then in disk 3, I had to place the following files:

BACKUP.EXE
CHKDSK.COM
CHKDSK32.DLL
FDISK.COM
FORMAT.COM
NLS.DLL
ODPANS.DLL
ODPRTDRV.EXE
OSDELETE.EXE
OSO001.MSG
RESTORE.EXE
SHPIINST.DLL
SYSINSTX.COM
TEDIT.EXE
TEDIT.HLP
UHPFS.DLL
VIOCALLS.DLL
XCOPY.EXE


Some of the files from the \OS2, \OS2\BOOT and \OS2\BOOT\DLL had to be copied.

When I completed resizing the hard disk, I had to boot from the installation diskette, disk 1 and disk 2 before entering the command prompt. Lastly, I inserted disk 3 and then entered this command to regain access to the drive:

CHKDSK C: /F

The command above fixes the errors that caused the drive to be rendered inaccessible. When that was finished, I used the FDISK /NEWMBR to write the new MBR code and lastly typed in SYSINSTX C: to transfer the system files and make the new drive bootable again! :)


However, there is one thing that bothers me. Although the size of the drive correctly reads as 4,094 MB, FDISK is showing that 4,091 MB is accessible and only 3 MB of that partition is not used. Here's a screenshot for proof: http://a.imageshack.us/img63/3340/os23mbgap.png

Is there a way to fix the 3 MB gap found in FDISK without destroying any data? If so, how can I do it? The current revision of my OS/2 system is internal revision 14.085_W4.

RobertM

Quote from: ppgrainbow on 2010.08.02, 23:21:42
However, there is one thing that bothers me. Although the size of the drive correctly reads as 4,094 MB, FDISK is showing that 4,091 MB is accessible and only 3 MB of that partition is not used. Here's a screenshot for proof: http://a.imageshack.us/img63/3340/os23mbgap.png

Is there a way to fix the 3 MB gap found in FDISK without destroying any data? If so, how can I do it? The current revision of my OS/2 system is internal revision 14.085_W4.

Nope. There is nothing wrong there. That all has to do with drive capacity, cylinder boundaries, and block sizes. There will virtually always be some unusable space after formatting - between 1MB and and 7MB usually.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


ppgrainbow

Quote from: RobertM on 2010.08.03, 00:17:19Nope. There is nothing wrong there. That all has to do with drive capacity, cylinder boundaries, and block sizes. There will virtually always be some unusable space after formatting - between 1MB and and 7MB usually.

I knew it. However, if you set up a hard disk image directly from FDISK, it would be the same thing, wouldn't it?

I'll report back to the forums, if I create a hard disk image larger than 7.88 GB and something goes wrong.