how to move filesystems?

G

Guest

Guest
Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general (More info?)

Is there a way of copying/moving a dirctory tree and preserve the
timestamps. This is for 100+ GByte filesystems, say when moving to
larger harddrives, etc.

I'm used to being able do this under UNIX, for example:
tar cf - . | (cd newdir; tar xBfp -) But UNIX tools (cygwin) under
windows fail on junctions, truncate paths, etc.

Ghost doesn't work -- well, it does, but it runs under DOS and
trickles at 200 MB/min, which is less than 5% of disk speed (these are
Maxtor Atlas 10K on an Ultra160 scsi bus), and bringing a system down
to DOS for the sake of moving filesystems is not an option. I'd prefer
to remount filesystems read-only and move data with refined tools.

robocopy.exe (using latest from Win2003 reskit) fails in that
subfolders have new modification dates (timestamps). I've read that
an earlier version had a /timfix switch, but that it had to run twice
-- once to copy and again to fix the time stamps. Geez, what a hack.

Any info on other tools, tips & tricks would be welcome, appreciated,
and helpful.
Thanks
Jaz
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general (More info?)

Hi,
Funny, the exact problem came up here this morning, with 135 Gbs.

Sorry, don't have a solution yet. Will post if I find one.

Actually, I could script a work-around if I could figure out how to set file
and folder times, something that's been on the back burner for a while.

Jerry
Psych Dept, UT Austin

"Jaz" <harbell@beerburp.com> wrote in message
news:3fkrb0tl21ri7uk8sq21b4bvmm2rns0m8l@4ax.com...
>
> Is there a way of copying/moving a dirctory tree and preserve the
> timestamps. This is for 100+ GByte filesystems, say when moving to
> larger harddrives, etc.
>
> I'm used to being able do this under UNIX, for example:
> tar cf - . | (cd newdir; tar xBfp -) But UNIX tools (cygwin) under
> windows fail on junctions, truncate paths, etc.
>
> Ghost doesn't work -- well, it does, but it runs under DOS and
> trickles at 200 MB/min, which is less than 5% of disk speed (these are
> Maxtor Atlas 10K on an Ultra160 scsi bus), and bringing a system down
> to DOS for the sake of moving filesystems is not an option. I'd prefer
> to remount filesystems read-only and move data with refined tools.
>
> robocopy.exe (using latest from Win2003 reskit) fails in that
> subfolders have new modification dates (timestamps). I've read that
> an earlier version had a /timfix switch, but that it had to run twice
> -- once to copy and again to fix the time stamps. Geez, what a hack.
>
> Any info on other tools, tips & tricks would be welcome, appreciated,
> and helpful.
> Thanks
> Jaz
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general (More info?)

Have you tried using the Backup Utility? Backup to a location, Restore to
the point you want to move the data to. It seems to keep most Timestamps. It
looks like it always changes the Folder Accessed time to Now and sometimes
changes the Folder Modified time to Now. Not sure why the variable behavior
with the Folder Modified. Files stay the same.

Jerry


"Jaz" <harbell@beerburp.com> wrote in message
news:3fkrb0tl21ri7uk8sq21b4bvmm2rns0m8l@4ax.com...
>
> Is there a way of copying/moving a dirctory tree and preserve the
> timestamps. This is for 100+ GByte filesystems, say when moving to
> larger harddrives, etc.
>
> I'm used to being able do this under UNIX, for example:
> tar cf - . | (cd newdir; tar xBfp -) But UNIX tools (cygwin) under
> windows fail on junctions, truncate paths, etc.
>
> Ghost doesn't work -- well, it does, but it runs under DOS and
> trickles at 200 MB/min, which is less than 5% of disk speed (these are
> Maxtor Atlas 10K on an Ultra160 scsi bus), and bringing a system down
> to DOS for the sake of moving filesystems is not an option. I'd prefer
> to remount filesystems read-only and move data with refined tools.
>
> robocopy.exe (using latest from Win2003 reskit) fails in that
> subfolders have new modification dates (timestamps). I've read that
> an earlier version had a /timfix switch, but that it had to run twice
> -- once to copy and again to fix the time stamps. Geez, what a hack.
>
> Any info on other tools, tips & tricks would be welcome, appreciated,
> and helpful.
> Thanks
> Jaz
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general (More info?)

"Jerry Parlee" <parlee@psy.utexas.edu> forgot to take the pills and
typed:
>Have you tried using the Backup Utility? Backup to a location, Restore to
>the point you want to move the data to. It seems to keep most Timestamps. It
>looks like it always changes the Folder Accessed time to Now and sometimes
>changes the Folder Modified time to Now. Not sure why the variable behavior
>with the Folder Modified. Files stay the same.
>
>Jerry
>
>
>"Jaz" <harbell@beerburp.com> wrote in message
>news:3fkrb0tl21ri7uk8sq21b4bvmm2rns0m8l@4ax.com...
>>
>> Is there a way of copying/moving a dirctory tree and preserve the
>> timestamps. This is for 100+ GByte filesystems, say when moving to
>> larger harddrives, etc.
>>
>> I'm used to being able do this under UNIX, for example:
>> tar cf - . | (cd newdir; tar xBfp -) But UNIX tools (cygwin) under
>> windows fail on junctions, truncate paths, etc.
>>
>> Ghost doesn't work -- well, it does, but it runs under DOS and
>> trickles at 200 MB/min, which is less than 5% of disk speed (these are
>> Maxtor Atlas 10K on an Ultra160 scsi bus), and bringing a system down
>> to DOS for the sake of moving filesystems is not an option. I'd prefer
>> to remount filesystems read-only and move data with refined tools.
>>
>> robocopy.exe (using latest from Win2003 reskit) fails in that
>> subfolders have new modification dates (timestamps). I've read that
>> an earlier version had a /timfix switch, but that it had to run twice
>> -- once to copy and again to fix the time stamps. Geez, what a hack.
>>
>> Any info on other tools, tips & tricks would be welcome, appreciated,
>> and helpful.
>> Thanks
>> Jaz

I have, but with these sizes it's inconvenient. First, these's no way
to stream the output to a second process to unpack, meaning that an
intermediary disk/tape/etc is required. Second is the time, which is
basically doubled. It just seems too silly to pack files into a
gigantic file-on-disk, or span tapes.

Jaz


(Please excuse the 'burp' when replying)
 

TRENDING THREADS