Jump to content

Problem Defragging Large File


Recommended Posts

Guest ColTom2
Posted

Hi:

 

I had a file that was over 13BG in size and the Windows defrag process

went fine defragging the file per se. However, when the defrag process tried

to move this large file it always hung up at 3%. As long as the file itself

was being defragged everything was OK, but when it came to trying to move

this file is where it always hung up.

 

Does anyone have a solution to defragging a large file of this size within

Windows XP?

 

Thanks

Guest Bill in Co.
Posted

Re: Problem Defragging Large File

 

ColTom2 wrote:

> Hi:

>

> I had a file that was over 13BG in size and the Windows defrag process

> went fine defragging the file per se. However, when the defrag process

> tried

> to move this large file it always hung up at 3%. As long as the file

> itself

> was being defragged everything was OK, but when it came to trying to move

> this file is where it always hung up.

>

> Does anyone have a solution to defragging a large file of this size

> within

> Windows XP?

>

> Thanks

 

That may well depend on just how much clear *unfragmented* disk space you

have left on your hard disk. If you don't have enough, it won't be able to

move it. 13 GB is really large; do you have a LOT of free, unfragmented,

disk space left on your hard drive for it do this on?

Guest Gerry
Posted

Re: Problem Defragging Large File

 

Tom

 

Bill is right but even with a lot of contiguous free space it may be

difficult. One way, which might work, would be to move the file out of

the partition. Run Disk Defragmenter to maximise contiguous free disk

space in the partition. Then before doing anything else copy the file

back to the partition so that it is written into the contiguous free

disk space.

 

--

 

 

 

Hope this helps.

 

Gerry

~~~~

FCA

Stourport, England

Enquire, plan and execute

~~~~~~~~~~~~~~~~~~~

 

 

 

ColTom2 wrote:

> Hi:

>

> I had a file that was over 13BG in size and the Windows defrag

> process went fine defragging the file per se. However, when the

> defrag process tried to move this large file it always hung up at 3%.

> As long as the file itself was being defragged everything was OK, but

> when it came to trying to move this file is where it always hung up.

>

> Does anyone have a solution to defragging a large file of this size

> within Windows XP?

>

> Thanks

Guest ColTom2
Posted

Re: Problem Defragging Large File

 

I thought afterwards about doing exactly what you indicated in moving the

file. I could just burn the file, remove it, defrag, and then restore the

file immediately afterwards and I believe that would work.

 

I have a 250GB hard drive with less than 50 GB used so that is not a

problem.

 

The problem was defrag in trying to move one file of over 13GB which it just

hung and apparently really can't handle in a timely fashion.

 

Thanks so much for your input.

 

I have a 250GB hard drive so that is not the problem,

"Gerry" <gerry@nospam.com> wrote in message

news:ecFbtF$tIHA.3716@TK2MSFTNGP05.phx.gbl...

Tom

 

Bill is right but even with a lot of contiguous free space it may be

difficult. One way, which might work, would be to move the file out of

the partition. Run Disk Defragmenter to maximise contiguous free disk

space in the partition. Then before doing anything else copy the file

back to the partition so that it is written into the contiguous free

disk space.

 

--

 

 

 

Hope this helps.

 

Gerry

~~~~

FCA

Stourport, England

Enquire, plan and execute

~~~~~~~~~~~~~~~~~~~

 

 

 

ColTom2 wrote:

> Hi:

>

> I had a file that was over 13BG in size and the Windows defrag

> process went fine defragging the file per se. However, when the

> defrag process tried to move this large file it always hung up at 3%.

> As long as the file itself was being defragged everything was OK, but

> when it came to trying to move this file is where it always hung up.

>

> Does anyone have a solution to defragging a large file of this size

> within Windows XP?

>

> Thanks

Guest Gerry
Posted

Re: Problem Defragging Large File

 

Tom

 

If you try it please let us know how it works out.

 

 

--

 

 

 

Hope this helps.

 

Gerry

~~~~

FCA

Stourport, England

Enquire, plan and execute

~~~~~~~~~~~~~~~~~~~

 

ColTom2 wrote:

> I thought afterwards about doing exactly what you indicated in moving

> the file. I could just burn the file, remove it, defrag, and then

> restore the file immediately afterwards and I believe that would work.

>

> I have a 250GB hard drive with less than 50 GB used so that is not a

> problem.

>

> The problem was defrag in trying to move one file of over 13GB which

> it just hung and apparently really can't handle in a timely fashion.

>

> Thanks so much for your input.

>

> I have a 250GB hard drive so that is not the problem,

> "Gerry" <gerry@nospam.com> wrote in message

> news:ecFbtF$tIHA.3716@TK2MSFTNGP05.phx.gbl...

> Tom

>

> Bill is right but even with a lot of contiguous free space it may be

> difficult. One way, which might work, would be to move the file out of

> the partition. Run Disk Defragmenter to maximise contiguous free disk

> space in the partition. Then before doing anything else copy the file

> back to the partition so that it is written into the contiguous free

> disk space.

>

>

> ColTom2 wrote:

>> Hi:

>>

>> I had a file that was over 13BG in size and the Windows defrag

>> process went fine defragging the file per se. However, when the

>> defrag process tried to move this large file it always hung up at 3%.

>> As long as the file itself was being defragged everything was OK, but

>> when it came to trying to move this file is where it always hung up.

>>

>> Does anyone have a solution to defragging a large file of this size

>> within Windows XP?

>>

>> Thanks

Guest Colin Barnhorst
Posted

Re: Problem Defragging Large File

 

Try downloading a trial copy of PerfectDisk or Diskeeper and letting it

defrag the file. You can uninstall the software afterwards. Either of

those defraggers are excellent at this particular type of defragging.

 

"ColTom2" <noemailaddress@nomail.com> wrote in message

news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

> Hi:

>

> I had a file that was over 13BG in size and the Windows defrag process

> went fine defragging the file per se. However, when the defrag process

> tried

> to move this large file it always hung up at 3%. As long as the file

> itself

> was being defragged everything was OK, but when it came to trying to move

> this file is where it always hung up.

>

> Does anyone have a solution to defragging a large file of this size

> within

> Windows XP?

>

> Thanks

>

>

Guest Bill in Co.
Posted

Re: Problem Defragging Large File

 

Probably be less and wear and tear (and faster!!) to do it the way Gerry

mentioned, however.

 

Colin Barnhorst wrote:

> Try downloading a trial copy of PerfectDisk or Diskeeper and letting it

> defrag the file. You can uninstall the software afterwards. Either of

> those defraggers are excellent at this particular type of defragging.

>

> "ColTom2" <noemailaddress@nomail.com> wrote in message

> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>> Hi:

>>

>> I had a file that was over 13BG in size and the Windows defrag process

>> went fine defragging the file per se. However, when the defrag process

>> tried

>> to move this large file it always hung up at 3%. As long as the file

>> itself

>> was being defragged everything was OK, but when it came to trying to move

>> this file is where it always hung up.

>>

>> Does anyone have a solution to defragging a large file of this size

>> within

>> Windows XP?

>>

>> Thanks

Guest Colin Barnhorst
Posted

Re: Problem Defragging Large File

 

It doesn't matter how he does it because a heavily fragged drive will suffer

far more wear and tear from head movement than any defragging operation will

ever cause. The easiest tip for reducing fragmentation in the first place

is to avoid using the Save command and stick to Save As. That way the new

or edited file is always contiguous.

 

"Bill in Co." <not_really_here@earthlink.net> wrote in message

news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

> Probably be less and wear and tear (and faster!!) to do it the way Gerry

> mentioned, however.

>

> Colin Barnhorst wrote:

>> Try downloading a trial copy of PerfectDisk or Diskeeper and letting it

>> defrag the file. You can uninstall the software afterwards. Either of

>> those defraggers are excellent at this particular type of defragging.

>>

>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>> Hi:

>>>

>>> I had a file that was over 13BG in size and the Windows defrag process

>>> went fine defragging the file per se. However, when the defrag process

>>> tried

>>> to move this large file it always hung up at 3%. As long as the file

>>> itself

>>> was being defragged everything was OK, but when it came to trying to

>>> move

>>> this file is where it always hung up.

>>>

>>> Does anyone have a solution to defragging a large file of this size

>>> within

>>> Windows XP?

>>>

>>> Thanks

>

>

Guest Bill in Co.
Posted

Re: Problem Defragging Large File

 

But see, if he removes and deletes the file, and then runs defrag, there

won't be much there to defrag so it will be fast, and then when he copies it

back *to a freshly defragmented drive*, it should be stored there in

contiguous sectors, right?

 

ALSO:

"Save as" always stores a contiguous file? And "save" doesn't? I

didn't know that. Do you have some reference article on that? (I'm

assuming we're not talking about just overwriting an existing file when

using Save, which may be different)

 

Colin Barnhorst wrote:

> It doesn't matter how he does it because a heavily fragged drive will

> suffer

> far more wear and tear from head movement than any defragging operation

> will

> ever cause. The easiest tip for reducing fragmentation in the first place

> is to avoid using the Save command and stick to Save As. That way the new

> or edited file is always contiguous.

>

> "Bill in Co." <not_really_here@earthlink.net> wrote in message

> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>> Probably be less and wear and tear (and faster!!) to do it the way Gerry

>> mentioned, however.

>>

>> Colin Barnhorst wrote:

>>> Try downloading a trial copy of PerfectDisk or Diskeeper and letting it

>>> defrag the file. You can uninstall the software afterwards. Either of

>>> those defraggers are excellent at this particular type of defragging.

>>>

>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>> Hi:

>>>>

>>>> I had a file that was over 13BG in size and the Windows defrag process

>>>> went fine defragging the file per se. However, when the defrag process

>>>> tried

>>>> to move this large file it always hung up at 3%. As long as the file

>>>> itself

>>>> was being defragged everything was OK, but when it came to trying to

>>>> move

>>>> this file is where it always hung up.

>>>>

>>>> Does anyone have a solution to defragging a large file of this size

>>>> within

>>>> Windows XP?

>>>>

>>>> Thanks

Guest Gerry
Posted

Re: Problem Defragging Large File

 

Colin

 

Your Save / Save As is a discussion point for another time. It has no

bearing on the problem raised by ColTom2.

 

 

 

~~~~

 

 

Gerry

~~~~

FCA

Stourport, England

Enquire, plan and execute

~~~~~~~~~~~~~~~~~~~

 

 

 

Colin Barnhorst wrote:

> It doesn't matter how he does it because a heavily fragged drive will

> suffer far more wear and tear from head movement than any defragging

> operation will ever cause. The easiest tip for reducing

> fragmentation in the first place is to avoid using the Save command

> and stick to Save As. That way the new or edited file is always

> contiguous.

> "Bill in Co." <not_really_here@earthlink.net> wrote in message

> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>> Probably be less and wear and tear (and faster!!) to do it the way

>> Gerry mentioned, however.

>>

>> Colin Barnhorst wrote:

>>> Try downloading a trial copy of PerfectDisk or Diskeeper and

>>> letting it defrag the file. You can uninstall the software

>>> afterwards. Either of those defraggers are excellent at this

>>> particular type of defragging. "ColTom2" <noemailaddress@nomail.com>

>>> wrote in message

>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>> Hi:

>>>>

>>>> I had a file that was over 13BG in size and the Windows defrag

>>>> process went fine defragging the file per se. However, when the

>>>> defrag process tried

>>>> to move this large file it always hung up at 3%. As long as the

>>>> file itself

>>>> was being defragged everything was OK, but when it came to trying

>>>> to move

>>>> this file is where it always hung up.

>>>>

>>>> Does anyone have a solution to defragging a large file of this

>>>> size within

>>>> Windows XP?

>>>>

>>>> Thanks

Guest Colin Barnhorst
Posted

Re: Problem Defragging Large File

 

It is how the two commands have always worked and why when you use the Save

As command you are prompted if the file already exists as to whether or not

you want to replace the existing one.

 

The Save command only saves the changes to the file and saves them in the

next available place large enough for the fragment. That can be anywhere on

the drive. The file manager then records a link and the next time the file

is read into memory the file system follows the links until all of the file

is in memory. That's what causes the heads to sometimes skip all over the

place when loading the file and why it takes a long time and a lot of disk

activity to load some files.

 

If the file is a series of fragments scattered all over the drive then

selecting Save As will write a new, contiguous copy in a location that can

hold it, thus eliminating the need for links. The file manager then marks

the old pieces as available and the next defrag will consolidate these

pieces of free space into larger contiguous areas available for writes. In

the meantime disk performance improves because the drive heads are moving

far less, shortening access time and reducing wear and tear. There is no

downside that I know of to using Save As except the additional step of

confirming the "overwrite". No overwrite takes place, of course, since it

is a new write. "Overwrite" is just an anecdotal descriptor for what really

happens.

 

This is a very old computer tip that is still valid. If you search the web

though you will see explanations of the difference between the two commands

as simply being that Save As offers the opportunity to create a new copy

while keeping the old one by changing the file name. That is one of the

reasons to sometimes use Save As but by no means the most useful IMHO.

 

It is understanding what the Save command does NOT do that is the key. It

does not save the entire file, but only the changes from the current

session. These are not written into the existing file but in a new location

large enough to hold the changes.

 

"Bill in Co." <not_really_here@earthlink.net> wrote in message

news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

> But see, if he removes and deletes the file, and then runs defrag, there

> won't be much there to defrag so it will be fast, and then when he copies

> it back *to a freshly defragmented drive*, it should be stored there in

> contiguous sectors, right?

>

> ALSO:

> "Save as" always stores a contiguous file? And "save" doesn't? I

> didn't know that. Do you have some reference article on that? (I'm

> assuming we're not talking about just overwriting an existing file when

> using Save, which may be different)

>

> Colin Barnhorst wrote:

>> It doesn't matter how he does it because a heavily fragged drive will

>> suffer

>> far more wear and tear from head movement than any defragging operation

>> will

>> ever cause. The easiest tip for reducing fragmentation in the first

>> place

>> is to avoid using the Save command and stick to Save As. That way the

>> new

>> or edited file is always contiguous.

>>

>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>> Probably be less and wear and tear (and faster!!) to do it the way Gerry

>>> mentioned, however.

>>>

>>> Colin Barnhorst wrote:

>>>> Try downloading a trial copy of PerfectDisk or Diskeeper and letting it

>>>> defrag the file. You can uninstall the software afterwards. Either of

>>>> those defraggers are excellent at this particular type of defragging.

>>>>

>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>> Hi:

>>>>>

>>>>> I had a file that was over 13BG in size and the Windows defrag

>>>>> process

>>>>> went fine defragging the file per se. However, when the defrag process

>>>>> tried

>>>>> to move this large file it always hung up at 3%. As long as the file

>>>>> itself

>>>>> was being defragged everything was OK, but when it came to trying to

>>>>> move

>>>>> this file is where it always hung up.

>>>>>

>>>>> Does anyone have a solution to defragging a large file of this size

>>>>> within

>>>>> Windows XP?

>>>>>

>>>>> Thanks

>

>

Guest Bill Sharpe
Posted

Re: Problem Defragging Large File

 

Colin Barnhorst wrote:

> It is how the two commands have always worked and why when you use the

> Save As command you are prompted if the file already exists as to

> whether or not you want to replace the existing one.

>

> The Save command only saves the changes to the file and saves them in

> the next available place large enough for the fragment. That can be

> anywhere on the drive. The file manager then records a link and the

> next time the file is read into memory the file system follows the links

> until all of the file is in memory. That's what causes the heads to

> sometimes skip all over the place when loading the file and why it takes

> a long time and a lot of disk activity to load some files.

>

> If the file is a series of fragments scattered all over the drive then

> selecting Save As will write a new, contiguous copy in a location that

> can hold it, thus eliminating the need for links. The file manager then

> marks the old pieces as available and the next defrag will consolidate

> these pieces of free space into larger contiguous areas available for

> writes. In the meantime disk performance improves because the drive

> heads are moving far less, shortening access time and reducing wear and

> tear. There is no downside that I know of to using Save As except the

> additional step of confirming the "overwrite". No overwrite takes

> place, of course, since it is a new write. "Overwrite" is just an

> anecdotal descriptor for what really happens.

>

> This is a very old computer tip that is still valid. If you search the

> web though you will see explanations of the difference between the two

> commands as simply being that Save As offers the opportunity to create a

> new copy while keeping the old one by changing the file name. That is

> one of the reasons to sometimes use Save As but by no means the most

> useful IMHO.

>

> It is understanding what the Save command does NOT do that is the key.

> It does not save the entire file, but only the changes from the current

> session. These are not written into the existing file but in a new

> location large enough to hold the changes.

>

> "Bill in Co." <not_really_here@earthlink.net> wrote in message

> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>> But see, if he removes and deletes the file, and then runs defrag,

>> there won't be much there to defrag so it will be fast, and then when

>> he copies it back *to a freshly defragmented drive*, it should be

>> stored there in contiguous sectors, right?

>>

>> ALSO:

>> "Save as" always stores a contiguous file? And "save" doesn't?

>> I didn't know that. Do you have some reference article on that?

>> (I'm assuming we're not talking about just overwriting an existing

>> file when using Save, which may be different)

>>

>> Colin Barnhorst wrote:

>>> It doesn't matter how he does it because a heavily fragged drive will

>>> suffer

>>> far more wear and tear from head movement than any defragging

>>> operation will

>>> ever cause. The easiest tip for reducing fragmentation in the first

>>> place

>>> is to avoid using the Save command and stick to Save As. That way

>>> the new

>>> or edited file is always contiguous.

>>>

>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>> Probably be less and wear and tear (and faster!!) to do it the way

>>>> Gerry

>>>> mentioned, however.

>>>>

>>>> Colin Barnhorst wrote:

>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper and

>>>>> letting it

>>>>> defrag the file. You can uninstall the software afterwards.

>>>>> Either of

>>>>> those defraggers are excellent at this particular type of defragging.

>>>>>

>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>> Hi:

>>>>>>

>>>>>> I had a file that was over 13BG in size and the Windows defrag

>>>>>> process

>>>>>> went fine defragging the file per se. However, when the defrag

>>>>>> process

>>>>>> tried

>>>>>> to move this large file it always hung up at 3%. As long as the file

>>>>>> itself

>>>>>> was being defragged everything was OK, but when it came to trying to

>>>>>> move

>>>>>> this file is where it always hung up.

>>>>>>

>>>>>> Does anyone have a solution to defragging a large file of this size

>>>>>> within

>>>>>> Windows XP?

>>>>>>

>>>>>> Thanks

>>

>>

>

If you don't change the file name, I would think "save as" would work

the same way as "save." If you do change the file name, yes, I'd expect

a contiguous file to be created. However, Save is a much faster

operation, Ctrl-S, with no dialog box to fill out.

 

Bill

Guest Colin Barnhorst
Posted

Re: Problem Defragging Large File

 

Save As always saves the whole file. When you confirm usage of the existing

file name it still writes a fresh, contiguous copy file and marks the old

one for deletion. When you change the filename it writes the new file with

the new name but does not mark the old one for deletion.

 

"Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

> Colin Barnhorst wrote:

>> It is how the two commands have always worked and why when you use the

>> Save As command you are prompted if the file already exists as to whether

>> or not you want to replace the existing one.

>>

>> The Save command only saves the changes to the file and saves them in the

>> next available place large enough for the fragment. That can be anywhere

>> on the drive. The file manager then records a link and the next time the

>> file is read into memory the file system follows the links until all of

>> the file is in memory. That's what causes the heads to sometimes skip

>> all over the place when loading the file and why it takes a long time and

>> a lot of disk activity to load some files.

>>

>> If the file is a series of fragments scattered all over the drive then

>> selecting Save As will write a new, contiguous copy in a location that

>> can hold it, thus eliminating the need for links. The file manager then

>> marks the old pieces as available and the next defrag will consolidate

>> these pieces of free space into larger contiguous areas available for

>> writes. In the meantime disk performance improves because the drive

>> heads are moving far less, shortening access time and reducing wear and

>> tear. There is no downside that I know of to using Save As except the

>> additional step of confirming the "overwrite". No overwrite takes place,

>> of course, since it is a new write. "Overwrite" is just an anecdotal

>> descriptor for what really happens.

>>

>> This is a very old computer tip that is still valid. If you search the

>> web though you will see explanations of the difference between the two

>> commands as simply being that Save As offers the opportunity to create a

>> new copy while keeping the old one by changing the file name. That is

>> one of the reasons to sometimes use Save As but by no means the most

>> useful IMHO.

>>

>> It is understanding what the Save command does NOT do that is the key.

>> It does not save the entire file, but only the changes from the current

>> session. These are not written into the existing file but in a new

>> location large enough to hold the changes.

>>

>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>> But see, if he removes and deletes the file, and then runs defrag, there

>>> won't be much there to defrag so it will be fast, and then when he

>>> copies it back *to a freshly defragmented drive*, it should be stored

>>> there in contiguous sectors, right?

>>>

>>> ALSO:

>>> "Save as" always stores a contiguous file? And "save" doesn't? I

>>> didn't know that. Do you have some reference article on that? (I'm

>>> assuming we're not talking about just overwriting an existing file when

>>> using Save, which may be different)

>>>

>>> Colin Barnhorst wrote:

>>>> It doesn't matter how he does it because a heavily fragged drive will

>>>> suffer

>>>> far more wear and tear from head movement than any defragging operation

>>>> will

>>>> ever cause. The easiest tip for reducing fragmentation in the first

>>>> place

>>>> is to avoid using the Save command and stick to Save As. That way the

>>>> new

>>>> or edited file is always contiguous.

>>>>

>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>> Probably be less and wear and tear (and faster!!) to do it the way

>>>>> Gerry

>>>>> mentioned, however.

>>>>>

>>>>> Colin Barnhorst wrote:

>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper and letting

>>>>>> it

>>>>>> defrag the file. You can uninstall the software afterwards. Either

>>>>>> of

>>>>>> those defraggers are excellent at this particular type of defragging.

>>>>>>

>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>> Hi:

>>>>>>>

>>>>>>> I had a file that was over 13BG in size and the Windows defrag

>>>>>>> process

>>>>>>> went fine defragging the file per se. However, when the defrag

>>>>>>> process

>>>>>>> tried

>>>>>>> to move this large file it always hung up at 3%. As long as the file

>>>>>>> itself

>>>>>>> was being defragged everything was OK, but when it came to trying to

>>>>>>> move

>>>>>>> this file is where it always hung up.

>>>>>>>

>>>>>>> Does anyone have a solution to defragging a large file of this size

>>>>>>> within

>>>>>>> Windows XP?

>>>>>>>

>>>>>>> Thanks

>>>

>>>

>>

> If you don't change the file name, I would think "save as" would work the

> same way as "save." If you do change the file name, yes, I'd expect a

> contiguous file to be created. However, Save is a much faster operation,

> Ctrl-S, with no dialog box to fill out.

>

> Bill

Guest Bill in Co.
Posted

Re: Problem Defragging Large File

 

Colin Barnhorst wrote:

> Save As always saves the whole file. When you confirm usage of the

> existing

> file name it still writes a fresh, contiguous copy file and marks the old

> one for deletion.

 

Are you sure? And you're also saying that just using SAVE will NOT do

that? (in both cases using the same file name of a file that is already on

the disk)

> When you change the filename it writes the new file with

> the new name but does not mark the old one for deletion.

 

But in both cases above, we're NOT changing the filename.

> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>> Colin Barnhorst wrote:

>>> It is how the two commands have always worked and why when you use the

>>> Save As command you are prompted if the file already exists as to

>>> whether

>>> or not you want to replace the existing one.

>>>

>>> The Save command only saves the changes to the file and saves them in

>>> the

>>> next available place large enough for the fragment. That can be

>>> anywhere

>>> on the drive. The file manager then records a link and the next time

>>> the

>>> file is read into memory the file system follows the links until all of

>>> the file is in memory. That's what causes the heads to sometimes skip

>>> all over the place when loading the file and why it takes a long time

>>> and

>>> a lot of disk activity to load some files.

>>>

>>> If the file is a series of fragments scattered all over the drive then

>>> selecting Save As will write a new, contiguous copy in a location that

>>> can hold it, thus eliminating the need for links. The file manager then

>>> marks the old pieces as available and the next defrag will consolidate

>>> these pieces of free space into larger contiguous areas available for

>>> writes. In the meantime disk performance improves because the drive

>>> heads are moving far less, shortening access time and reducing wear and

>>> tear. There is no downside that I know of to using Save As except the

>>> additional step of confirming the "overwrite". No overwrite takes

>>> place,

>>> of course, since it is a new write. "Overwrite" is just an anecdotal

>>> descriptor for what really happens.

>>>

>>> This is a very old computer tip that is still valid. If you search the

>>> web though you will see explanations of the difference between the two

>>> commands as simply being that Save As offers the opportunity to create a

>>> new copy while keeping the old one by changing the file name. That is

>>> one of the reasons to sometimes use Save As but by no means the most

>>> useful IMHO.

>>>

>>> It is understanding what the Save command does NOT do that is the key.

>>> It does not save the entire file, but only the changes from the current

>>> session. These are not written into the existing file but in a new

>>> location large enough to hold the changes.

>>>

>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>> But see, if he removes and deletes the file, and then runs defrag,

>>>> there

>>>> won't be much there to defrag so it will be fast, and then when he

>>>> copies it back *to a freshly defragmented drive*, it should be stored

>>>> there in contiguous sectors, right?

>>>>

>>>> ALSO:

>>>> "Save as" always stores a contiguous file? And "save" doesn't? I

>>>> didn't know that. Do you have some reference article on that?

>>>> (I'm

>>>> assuming we're not talking about just overwriting an existing file when

>>>> using Save, which may be different)

>>>>

>>>> Colin Barnhorst wrote:

>>>>> It doesn't matter how he does it because a heavily fragged drive will

>>>>> suffer

>>>>> far more wear and tear from head movement than any defragging

>>>>> operation

>>>>> will

>>>>> ever cause. The easiest tip for reducing fragmentation in the first

>>>>> place

>>>>> is to avoid using the Save command and stick to Save As. That way the

>>>>> new

>>>>> or edited file is always contiguous.

>>>>>

>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>> Probably be less and wear and tear (and faster!!) to do it the way

>>>>>> Gerry

>>>>>> mentioned, however.

>>>>>>

>>>>>> Colin Barnhorst wrote:

>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper and letting

>>>>>>> it

>>>>>>> defrag the file. You can uninstall the software afterwards. Either

>>>>>>> of

>>>>>>> those defraggers are excellent at this particular type of

>>>>>>> defragging.

>>>>>>>

>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>> Hi:

>>>>>>>>

>>>>>>>> I had a file that was over 13BG in size and the Windows defrag

>>>>>>>> process

>>>>>>>> went fine defragging the file per se. However, when the defrag

>>>>>>>> process

>>>>>>>> tried

>>>>>>>> to move this large file it always hung up at 3%. As long as the

>>>>>>>> file

>>>>>>>> itself

>>>>>>>> was being defragged everything was OK, but when it came to trying

>>>>>>>> to

>>>>>>>> move

>>>>>>>> this file is where it always hung up.

>>>>>>>>

>>>>>>>> Does anyone have a solution to defragging a large file of this

>>>>>>>> size

>>>>>>>> within

>>>>>>>> Windows XP?

>>>>>>>>

>>>>>>>> Thanks

>>>>

>>>>

>>>

>> If you don't change the file name, I would think "save as" would work the

>> same way as "save." If you do change the file name, yes, I'd expect a

>> contiguous file to be created. However, Save is a much faster operation,

>> Ctrl-S, with no dialog box to fill out.

>>

>> Bill

Guest Bill in Co.
Posted

Re: Problem Defragging Large File

 

Actually, I'm pretty certain I was right the first time. There is NO

difference between using "Save" and "Save As", EXCEPT for allowing for a

different filename.

 

If the file is already there and fragmented, and you save over it (either

way!), it will STAY fragmented.

 

If the file isn't there, and you save it, it makes no difference which way

you save it.

 

If I'm wrong, show me the site supporting that.

 

And the fact that the operating system marks the first cluster to indicate

the file is deleted has nothing to do with this *specific* discussion.

 

Bill in Co. wrote:

> Colin Barnhorst wrote:

>> Save As always saves the whole file. When you confirm usage of the

>> existing

>> file name it still writes a fresh, contiguous copy file and marks the old

>> one for deletion.

>

> Are you sure? And you're also saying that just using SAVE will NOT do

> that? (in both cases using the same file name of a file that is already

> on

> the disk)

>

>> When you change the filename it writes the new file with

>> the new name but does not mark the old one for deletion.

>

> But in both cases above, we're NOT changing the filename.

>

>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>> Colin Barnhorst wrote:

>>>> It is how the two commands have always worked and why when you use the

>>>> Save As command you are prompted if the file already exists as to

>>>> whether

>>>> or not you want to replace the existing one.

>>>>

>>>> The Save command only saves the changes to the file and saves them in

>>>> the next available place large enough for the fragment. That can be

>>>> anywhere

>>>> on the drive. The file manager then records a link and the next time

>>>> the

>>>> file is read into memory the file system follows the links until all of

>>>> the file is in memory. That's what causes the heads to sometimes skip

>>>> all over the place when loading the file and why it takes a long time

>>>> and a lot of disk activity to load some files.

>>>>

>>>> If the file is a series of fragments scattered all over the drive then

>>>> selecting Save As will write a new, contiguous copy in a location that

>>>> can hold it, thus eliminating the need for links. The file manager

>>>> then

>>>> marks the old pieces as available and the next defrag will consolidate

>>>> these pieces of free space into larger contiguous areas available for

>>>> writes. In the meantime disk performance improves because the drive

>>>> heads are moving far less, shortening access time and reducing wear and

>>>> tear. There is no downside that I know of to using Save As except the

>>>> additional step of confirming the "overwrite". No overwrite takes

>>>> place,

>>>> of course, since it is a new write. "Overwrite" is just an anecdotal

>>>> descriptor for what really happens.

>>>>

>>>> This is a very old computer tip that is still valid. If you search the

>>>> web though you will see explanations of the difference between the two

>>>> commands as simply being that Save As offers the opportunity to create

>>>> a

>>>> new copy while keeping the old one by changing the file name. That is

>>>> one of the reasons to sometimes use Save As but by no means the most

>>>> useful IMHO.

>>>>

>>>> It is understanding what the Save command does NOT do that is the key.

>>>> It does not save the entire file, but only the changes from the current

>>>> session. These are not written into the existing file but in a new

>>>> location large enough to hold the changes.

>>>>

>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>> But see, if he removes and deletes the file, and then runs defrag,

>>>>> there

>>>>> won't be much there to defrag so it will be fast, and then when he

>>>>> copies it back *to a freshly defragmented drive*, it should be stored

>>>>> there in contiguous sectors, right?

>>>>>

>>>>> ALSO:

>>>>> "Save as" always stores a contiguous file? And "save" doesn't?

>>>>> I

>>>>> didn't know that. Do you have some reference article on that? (I'm

>>>>> assuming we're not talking about just overwriting an existing file

>>>>> when

>>>>> using Save, which may be different)

>>>>>

>>>>> Colin Barnhorst wrote:

>>>>>> It doesn't matter how he does it because a heavily fragged drive will

>>>>>> suffer far more wear and tear from head movement than any defragging

>>>>>> operation will

>>>>>> ever cause. The easiest tip for reducing fragmentation in the first

>>>>>> place

>>>>>> is to avoid using the Save command and stick to Save As. That way

>>>>>> the

>>>>>> new or edited file is always contiguous.

>>>>>>

>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>> Probably be less and wear and tear (and faster!!) to do it the way

>>>>>>> Gerry mentioned, however.

>>>>>>>

>>>>>>> Colin Barnhorst wrote:

>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper and

>>>>>>>> letting

>>>>>>>> it defrag the file. You can uninstall the software afterwards.

>>>>>>>> Either

>>>>>>>> of those defraggers are excellent at this particular type of

>>>>>>>> defragging.

>>>>>>>>

>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>> Hi:

>>>>>>>>>

>>>>>>>>> I had a file that was over 13BG in size and the Windows defrag

>>>>>>>>> process

>>>>>>>>> went fine defragging the file per se. However, when the defrag

>>>>>>>>> process tried

>>>>>>>>> to move this large file it always hung up at 3%. As long as the

>>>>>>>>> file itself

>>>>>>>>> was being defragged everything was OK, but when it came to trying

>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>

>>>>>>>>> Does anyone have a solution to defragging a large file of this

>>>>>>>>> size

>>>>>>>>> within Windows XP?

>>>>>>>>>

>>>>>>>>> Thanks

>>>>>

>>>>>

>>>>

>>> If you don't change the file name, I would think "save as" would work

>>> the

>>> same way as "save." If you do change the file name, yes, I'd expect a

>>> contiguous file to be created. However, Save is a much faster operation,

>>> Ctrl-S, with no dialog box to fill out.

>>>

>>> Bill

Guest Colin Barnhorst
Posted

Re: Problem Defragging Large File

 

Save As doesn't save over it. It saves in a new location regardless of

whether you give it a new filename or not. The difference is whether or not

the old copy stays (if you give a new name) or is marked for deletion.

 

"Bill in Co." <not_really_here@earthlink.net> wrote in message

news:eI$K%23bJuIHA.4876@TK2MSFTNGP02.phx.gbl...

> Actually, I'm pretty certain I was right the first time. There is NO

> difference between using "Save" and "Save As", EXCEPT for allowing for a

> different filename.

>

> If the file is already there and fragmented, and you save over it (either

> way!), it will STAY fragmented.

>

> If the file isn't there, and you save it, it makes no difference which way

> you save it.

>

> If I'm wrong, show me the site supporting that.

>

> And the fact that the operating system marks the first cluster to indicate

> the file is deleted has nothing to do with this *specific* discussion.

>

> Bill in Co. wrote:

>> Colin Barnhorst wrote:

>>> Save As always saves the whole file. When you confirm usage of the

>>> existing

>>> file name it still writes a fresh, contiguous copy file and marks the

>>> old

>>> one for deletion.

>>

>> Are you sure? And you're also saying that just using SAVE will NOT do

>> that? (in both cases using the same file name of a file that is already

>> on

>> the disk)

>>

>>> When you change the filename it writes the new file with

>>> the new name but does not mark the old one for deletion.

>>

>> But in both cases above, we're NOT changing the filename.

>>

>>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>>> Colin Barnhorst wrote:

>>>>> It is how the two commands have always worked and why when you use the

>>>>> Save As command you are prompted if the file already exists as to

>>>>> whether

>>>>> or not you want to replace the existing one.

>>>>>

>>>>> The Save command only saves the changes to the file and saves them in

>>>>> the next available place large enough for the fragment. That can be

>>>>> anywhere

>>>>> on the drive. The file manager then records a link and the next time

>>>>> the

>>>>> file is read into memory the file system follows the links until all

>>>>> of

>>>>> the file is in memory. That's what causes the heads to sometimes skip

>>>>> all over the place when loading the file and why it takes a long time

>>>>> and a lot of disk activity to load some files.

>>>>>

>>>>> If the file is a series of fragments scattered all over the drive then

>>>>> selecting Save As will write a new, contiguous copy in a location that

>>>>> can hold it, thus eliminating the need for links. The file manager

>>>>> then

>>>>> marks the old pieces as available and the next defrag will consolidate

>>>>> these pieces of free space into larger contiguous areas available for

>>>>> writes. In the meantime disk performance improves because the drive

>>>>> heads are moving far less, shortening access time and reducing wear

>>>>> and

>>>>> tear. There is no downside that I know of to using Save As except the

>>>>> additional step of confirming the "overwrite". No overwrite takes

>>>>> place,

>>>>> of course, since it is a new write. "Overwrite" is just an anecdotal

>>>>> descriptor for what really happens.

>>>>>

>>>>> This is a very old computer tip that is still valid. If you search

>>>>> the

>>>>> web though you will see explanations of the difference between the two

>>>>> commands as simply being that Save As offers the opportunity to create

>>>>> a

>>>>> new copy while keeping the old one by changing the file name. That is

>>>>> one of the reasons to sometimes use Save As but by no means the most

>>>>> useful IMHO.

>>>>>

>>>>> It is understanding what the Save command does NOT do that is the key.

>>>>> It does not save the entire file, but only the changes from the

>>>>> current

>>>>> session. These are not written into the existing file but in a new

>>>>> location large enough to hold the changes.

>>>>>

>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>>> But see, if he removes and deletes the file, and then runs defrag,

>>>>>> there

>>>>>> won't be much there to defrag so it will be fast, and then when he

>>>>>> copies it back *to a freshly defragmented drive*, it should be stored

>>>>>> there in contiguous sectors, right?

>>>>>>

>>>>>> ALSO:

>>>>>> "Save as" always stores a contiguous file? And "save" doesn't? I

>>>>>> didn't know that. Do you have some reference article on that? (I'm

>>>>>> assuming we're not talking about just overwriting an existing file

>>>>>> when

>>>>>> using Save, which may be different)

>>>>>>

>>>>>> Colin Barnhorst wrote:

>>>>>>> It doesn't matter how he does it because a heavily fragged drive

>>>>>>> will

>>>>>>> suffer far more wear and tear from head movement than any defragging

>>>>>>> operation will

>>>>>>> ever cause. The easiest tip for reducing fragmentation in the first

>>>>>>> place

>>>>>>> is to avoid using the Save command and stick to Save As. That way

>>>>>>> the

>>>>>>> new or edited file is always contiguous.

>>>>>>>

>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>>> Probably be less and wear and tear (and faster!!) to do it the way

>>>>>>>> Gerry mentioned, however.

>>>>>>>>

>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper and

>>>>>>>>> letting

>>>>>>>>> it defrag the file. You can uninstall the software afterwards.

>>>>>>>>> Either

>>>>>>>>> of those defraggers are excellent at this particular type of

>>>>>>>>> defragging.

>>>>>>>>>

>>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>>> Hi:

>>>>>>>>>>

>>>>>>>>>> I had a file that was over 13BG in size and the Windows defrag

>>>>>>>>>> process

>>>>>>>>>> went fine defragging the file per se. However, when the defrag

>>>>>>>>>> process tried

>>>>>>>>>> to move this large file it always hung up at 3%. As long as the

>>>>>>>>>> file itself

>>>>>>>>>> was being defragged everything was OK, but when it came to trying

>>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>>

>>>>>>>>>> Does anyone have a solution to defragging a large file of this

>>>>>>>>>> size

>>>>>>>>>> within Windows XP?

>>>>>>>>>>

>>>>>>>>>> Thanks

>>>>>>

>>>>>>

>>>>>

>>>> If you don't change the file name, I would think "save as" would work

>>>> the

>>>> same way as "save." If you do change the file name, yes, I'd expect a

>>>> contiguous file to be created. However, Save is a much faster

>>>> operation,

>>>> Ctrl-S, with no dialog box to fill out.

>>>>

>>>> Bill

>

>

Guest Bill in Co.
Posted

Re: Problem Defragging Large File

 

I don't think that's true (that "Save As" saves in a new location, and Save

doesn't). In either case, if the file exists, it will be overwritten in

the same location(s), to the best of my knowledge (meaning it will be

fragmented, too, since the operating system just looks for free clusters).

 

Colin Barnhorst wrote:

> Save As doesn't save over it. It saves in a new location regardless of

> whether you give it a new filename or not. The difference is whether or

> not

> the old copy stays (if you give a new name) or is marked for deletion.

>

> "Bill in Co." <not_really_here@earthlink.net> wrote in message

> news:eI$K%23bJuIHA.4876@TK2MSFTNGP02.phx.gbl...

>> Actually, I'm pretty certain I was right the first time. There is NO

>> difference between using "Save" and "Save As", EXCEPT for allowing for a

>> different filename.

>>

>> If the file is already there and fragmented, and you save over it (either

>> way!), it will STAY fragmented.

>>

>> If the file isn't there, and you save it, it makes no difference which

>> way

>> you save it.

>>

>> If I'm wrong, show me the site supporting that.

>>

>> And the fact that the operating system marks the first cluster to

>> indicate

>> the file is deleted has nothing to do with this *specific* discussion.

>>

>> Bill in Co. wrote:

>>> Colin Barnhorst wrote:

>>>> Save As always saves the whole file. When you confirm usage of the

>>>> existing

>>>> file name it still writes a fresh, contiguous copy file and marks the

>>>> old

>>>> one for deletion.

>>>

>>> Are you sure? And you're also saying that just using SAVE will NOT do

>>> that? (in both cases using the same file name of a file that is already

>>> on

>>> the disk)

>>>

>>>> When you change the filename it writes the new file with

>>>> the new name but does not mark the old one for deletion.

>>>

>>> But in both cases above, we're NOT changing the filename.

>>>

>>>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>>>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>>>> Colin Barnhorst wrote:

>>>>>> It is how the two commands have always worked and why when you use

>>>>>> the

>>>>>> Save As command you are prompted if the file already exists as to

>>>>>> whether

>>>>>> or not you want to replace the existing one.

>>>>>>

>>>>>> The Save command only saves the changes to the file and saves them in

>>>>>> the next available place large enough for the fragment. That can be

>>>>>> anywhere

>>>>>> on the drive. The file manager then records a link and the next time

>>>>>> the

>>>>>> file is read into memory the file system follows the links until all

>>>>>> of

>>>>>> the file is in memory. That's what causes the heads to sometimes

>>>>>> skip

>>>>>> all over the place when loading the file and why it takes a long time

>>>>>> and a lot of disk activity to load some files.

>>>>>>

>>>>>> If the file is a series of fragments scattered all over the drive

>>>>>> then

>>>>>> selecting Save As will write a new, contiguous copy in a location

>>>>>> that

>>>>>> can hold it, thus eliminating the need for links. The file manager

>>>>>> then

>>>>>> marks the old pieces as available and the next defrag will

>>>>>> consolidate

>>>>>> these pieces of free space into larger contiguous areas available for

>>>>>> writes. In the meantime disk performance improves because the drive

>>>>>> heads are moving far less, shortening access time and reducing wear

>>>>>> and

>>>>>> tear. There is no downside that I know of to using Save As except

>>>>>> the

>>>>>> additional step of confirming the "overwrite". No overwrite takes

>>>>>> place,

>>>>>> of course, since it is a new write. "Overwrite" is just an anecdotal

>>>>>> descriptor for what really happens.

>>>>>>

>>>>>> This is a very old computer tip that is still valid. If you search

>>>>>> the

>>>>>> web though you will see explanations of the difference between the

>>>>>> two

>>>>>> commands as simply being that Save As offers the opportunity to

>>>>>> create

>>>>>> a

>>>>>> new copy while keeping the old one by changing the file name. That

>>>>>> is

>>>>>> one of the reasons to sometimes use Save As but by no means the most

>>>>>> useful IMHO.

>>>>>>

>>>>>> It is understanding what the Save command does NOT do that is the

>>>>>> key.

>>>>>> It does not save the entire file, but only the changes from the

>>>>>> current

>>>>>> session. These are not written into the existing file but in a new

>>>>>> location large enough to hold the changes.

>>>>>>

>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>>>> But see, if he removes and deletes the file, and then runs defrag,

>>>>>>> there

>>>>>>> won't be much there to defrag so it will be fast, and then when he

>>>>>>> copies it back *to a freshly defragmented drive*, it should be

>>>>>>> stored

>>>>>>> there in contiguous sectors, right?

>>>>>>>

>>>>>>> ALSO:

>>>>>>> "Save as" always stores a contiguous file? And "save" doesn't? I

>>>>>>> didn't know that. Do you have some reference article on that?

>>>>>>> (I'm

>>>>>>> assuming we're not talking about just overwriting an existing file

>>>>>>> when

>>>>>>> using Save, which may be different)

>>>>>>>

>>>>>>> Colin Barnhorst wrote:

>>>>>>>> It doesn't matter how he does it because a heavily fragged drive

>>>>>>>> will

>>>>>>>> suffer far more wear and tear from head movement than any

>>>>>>>> defragging

>>>>>>>> operation will

>>>>>>>> ever cause. The easiest tip for reducing fragmentation in the

>>>>>>>> first

>>>>>>>> place

>>>>>>>> is to avoid using the Save command and stick to Save As. That way

>>>>>>>> the

>>>>>>>> new or edited file is always contiguous.

>>>>>>>>

>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>>> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>>>> Probably be less and wear and tear (and faster!!) to do it the way

>>>>>>>>> Gerry mentioned, however.

>>>>>>>>>

>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper and

>>>>>>>>>> letting

>>>>>>>>>> it defrag the file. You can uninstall the software afterwards.

>>>>>>>>>> Either

>>>>>>>>>> of those defraggers are excellent at this particular type of

>>>>>>>>>> defragging.

>>>>>>>>>>

>>>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>>>> Hi:

>>>>>>>>>>>

>>>>>>>>>>> I had a file that was over 13BG in size and the Windows defrag

>>>>>>>>>>> process

>>>>>>>>>>> went fine defragging the file per se. However, when the defrag

>>>>>>>>>>> process tried

>>>>>>>>>>> to move this large file it always hung up at 3%. As long as the

>>>>>>>>>>> file itself

>>>>>>>>>>> was being defragged everything was OK, but when it came to

>>>>>>>>>>> trying

>>>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>>>

>>>>>>>>>>> Does anyone have a solution to defragging a large file of this

>>>>>>>>>>> size

>>>>>>>>>>> within Windows XP?

>>>>>>>>>>>

>>>>>>>>>>> Thanks

>>>>>>>

>>>>>>>

>>>>>>

>>>>> If you don't change the file name, I would think "save as" would work

>>>>> the

>>>>> same way as "save." If you do change the file name, yes, I'd expect a

>>>>> contiguous file to be created. However, Save is a much faster

>>>>> operation,

>>>>> Ctrl-S, with no dialog box to fill out.

>>>>>

>>>>> Bill

Guest Colin Barnhorst
Posted

Re: Problem Defragging Large File

 

Save As saves a contiguous file in a new location. Save saves only the

changes in a new location.

 

"Bill in Co." <not_really_here@earthlink.net> wrote in message

news:%23KEFfrKuIHA.748@TK2MSFTNGP05.phx.gbl...

>I don't think that's true (that "Save As" saves in a new location, and Save

>doesn't). In either case, if the file exists, it will be overwritten in

>the same location(s), to the best of my knowledge (meaning it will be

>fragmented, too, since the operating system just looks for free clusters).

>

> Colin Barnhorst wrote:

>> Save As doesn't save over it. It saves in a new location regardless of

>> whether you give it a new filename or not. The difference is whether or

>> not

>> the old copy stays (if you give a new name) or is marked for deletion.

>>

>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>> news:eI$K%23bJuIHA.4876@TK2MSFTNGP02.phx.gbl...

>>> Actually, I'm pretty certain I was right the first time. There is NO

>>> difference between using "Save" and "Save As", EXCEPT for allowing for a

>>> different filename.

>>>

>>> If the file is already there and fragmented, and you save over it

>>> (either

>>> way!), it will STAY fragmented.

>>>

>>> If the file isn't there, and you save it, it makes no difference which

>>> way

>>> you save it.

>>>

>>> If I'm wrong, show me the site supporting that.

>>>

>>> And the fact that the operating system marks the first cluster to

>>> indicate

>>> the file is deleted has nothing to do with this *specific* discussion.

>>>

>>> Bill in Co. wrote:

>>>> Colin Barnhorst wrote:

>>>>> Save As always saves the whole file. When you confirm usage of the

>>>>> existing

>>>>> file name it still writes a fresh, contiguous copy file and marks the

>>>>> old

>>>>> one for deletion.

>>>>

>>>> Are you sure? And you're also saying that just using SAVE will NOT do

>>>> that? (in both cases using the same file name of a file that is

>>>> already

>>>> on

>>>> the disk)

>>>>

>>>>> When you change the filename it writes the new file with

>>>>> the new name but does not mark the old one for deletion.

>>>>

>>>> But in both cases above, we're NOT changing the filename.

>>>>

>>>>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>>>>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>>>>> Colin Barnhorst wrote:

>>>>>>> It is how the two commands have always worked and why when you use

>>>>>>> the

>>>>>>> Save As command you are prompted if the file already exists as to

>>>>>>> whether

>>>>>>> or not you want to replace the existing one.

>>>>>>>

>>>>>>> The Save command only saves the changes to the file and saves them

>>>>>>> in

>>>>>>> the next available place large enough for the fragment. That can be

>>>>>>> anywhere

>>>>>>> on the drive. The file manager then records a link and the next

>>>>>>> time

>>>>>>> the

>>>>>>> file is read into memory the file system follows the links until all

>>>>>>> of

>>>>>>> the file is in memory. That's what causes the heads to sometimes

>>>>>>> skip

>>>>>>> all over the place when loading the file and why it takes a long

>>>>>>> time

>>>>>>> and a lot of disk activity to load some files.

>>>>>>>

>>>>>>> If the file is a series of fragments scattered all over the drive

>>>>>>> then

>>>>>>> selecting Save As will write a new, contiguous copy in a location

>>>>>>> that

>>>>>>> can hold it, thus eliminating the need for links. The file manager

>>>>>>> then

>>>>>>> marks the old pieces as available and the next defrag will

>>>>>>> consolidate

>>>>>>> these pieces of free space into larger contiguous areas available

>>>>>>> for

>>>>>>> writes. In the meantime disk performance improves because the drive

>>>>>>> heads are moving far less, shortening access time and reducing wear

>>>>>>> and

>>>>>>> tear. There is no downside that I know of to using Save As except

>>>>>>> the

>>>>>>> additional step of confirming the "overwrite". No overwrite takes

>>>>>>> place,

>>>>>>> of course, since it is a new write. "Overwrite" is just an

>>>>>>> anecdotal

>>>>>>> descriptor for what really happens.

>>>>>>>

>>>>>>> This is a very old computer tip that is still valid. If you search

>>>>>>> the

>>>>>>> web though you will see explanations of the difference between the

>>>>>>> two

>>>>>>> commands as simply being that Save As offers the opportunity to

>>>>>>> create

>>>>>>> a

>>>>>>> new copy while keeping the old one by changing the file name. That

>>>>>>> is

>>>>>>> one of the reasons to sometimes use Save As but by no means the most

>>>>>>> useful IMHO.

>>>>>>>

>>>>>>> It is understanding what the Save command does NOT do that is the

>>>>>>> key.

>>>>>>> It does not save the entire file, but only the changes from the

>>>>>>> current

>>>>>>> session. These are not written into the existing file but in a new

>>>>>>> location large enough to hold the changes.

>>>>>>>

>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>>>>> But see, if he removes and deletes the file, and then runs defrag,

>>>>>>>> there

>>>>>>>> won't be much there to defrag so it will be fast, and then when he

>>>>>>>> copies it back *to a freshly defragmented drive*, it should be

>>>>>>>> stored

>>>>>>>> there in contiguous sectors, right?

>>>>>>>>

>>>>>>>> ALSO:

>>>>>>>> "Save as" always stores a contiguous file? And "save" doesn't? I

>>>>>>>> didn't know that. Do you have some reference article on that?

>>>>>>>> (I'm

>>>>>>>> assuming we're not talking about just overwriting an existing file

>>>>>>>> when

>>>>>>>> using Save, which may be different)

>>>>>>>>

>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>> It doesn't matter how he does it because a heavily fragged drive

>>>>>>>>> will

>>>>>>>>> suffer far more wear and tear from head movement than any

>>>>>>>>> defragging

>>>>>>>>> operation will

>>>>>>>>> ever cause. The easiest tip for reducing fragmentation in the

>>>>>>>>> first

>>>>>>>>> place

>>>>>>>>> is to avoid using the Save command and stick to Save As. That way

>>>>>>>>> the

>>>>>>>>> new or edited file is always contiguous.

>>>>>>>>>

>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>>>> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>>>>> Probably be less and wear and tear (and faster!!) to do it the

>>>>>>>>>> way

>>>>>>>>>> Gerry mentioned, however.

>>>>>>>>>>

>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper and

>>>>>>>>>>> letting

>>>>>>>>>>> it defrag the file. You can uninstall the software afterwards.

>>>>>>>>>>> Either

>>>>>>>>>>> of those defraggers are excellent at this particular type of

>>>>>>>>>>> defragging.

>>>>>>>>>>>

>>>>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>>>>> Hi:

>>>>>>>>>>>>

>>>>>>>>>>>> I had a file that was over 13BG in size and the Windows defrag

>>>>>>>>>>>> process

>>>>>>>>>>>> went fine defragging the file per se. However, when the defrag

>>>>>>>>>>>> process tried

>>>>>>>>>>>> to move this large file it always hung up at 3%. As long as the

>>>>>>>>>>>> file itself

>>>>>>>>>>>> was being defragged everything was OK, but when it came to

>>>>>>>>>>>> trying

>>>>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>>>>

>>>>>>>>>>>> Does anyone have a solution to defragging a large file of this

>>>>>>>>>>>> size

>>>>>>>>>>>> within Windows XP?

>>>>>>>>>>>>

>>>>>>>>>>>> Thanks

>>>>>>>>

>>>>>>>>

>>>>>>>

>>>>>> If you don't change the file name, I would think "save as" would work

>>>>>> the

>>>>>> same way as "save." If you do change the file name, yes, I'd expect a

>>>>>> contiguous file to be created. However, Save is a much faster

>>>>>> operation,

>>>>>> Ctrl-S, with no dialog box to fill out.

>>>>>>

>>>>>> Bill

>

>

Guest Gerry
Posted

Re: Problem Defragging Large File

 

Colin

 

What you say about Save As depends on how large the file is and whether

the next available free disk space is of sufficient size to accomodate

the file.

 

--

 

 

 

Hope this helps.

 

Gerry

~~~~

FCA

Stourport, England

Enquire, plan and execute

~~~~~~~~~~~~~~~~~~~

 

Colin Barnhorst wrote:

> Save As saves a contiguous file in a new location. Save saves only

> the changes in a new location.

>

> "Bill in Co." <not_really_here@earthlink.net> wrote in message

> news:%23KEFfrKuIHA.748@TK2MSFTNGP05.phx.gbl...

>> I don't think that's true (that "Save As" saves in a new location,

>> and Save doesn't). In either case, if the file exists, it will be

>> overwritten in the same location(s), to the best of my knowledge

>> (meaning it will be fragmented, too, since the operating system just

>> looks for free clusters). Colin Barnhorst wrote:

>>> Save As doesn't save over it. It saves in a new location

>>> regardless of whether you give it a new filename or not. The

>>> difference is whether or not

>>> the old copy stays (if you give a new name) or is marked for

>>> deletion. "Bill in Co." <not_really_here@earthlink.net> wrote in

>>> message

>>> news:eI$K%23bJuIHA.4876@TK2MSFTNGP02.phx.gbl...

>>>> Actually, I'm pretty certain I was right the first time. There

>>>> is NO difference between using "Save" and "Save As", EXCEPT for

>>>> allowing for a different filename.

>>>>

>>>> If the file is already there and fragmented, and you save over it

>>>> (either

>>>> way!), it will STAY fragmented.

>>>>

>>>> If the file isn't there, and you save it, it makes no difference

>>>> which way

>>>> you save it.

>>>>

>>>> If I'm wrong, show me the site supporting that.

>>>>

>>>> And the fact that the operating system marks the first cluster to

>>>> indicate

>>>> the file is deleted has nothing to do with this *specific*

>>>> discussion. Bill in Co. wrote:

>>>>> Colin Barnhorst wrote:

>>>>>> Save As always saves the whole file. When you confirm usage of

>>>>>> the existing

>>>>>> file name it still writes a fresh, contiguous copy file and

>>>>>> marks the old

>>>>>> one for deletion.

>>>>>

>>>>> Are you sure? And you're also saying that just using SAVE will

>>>>> NOT do that? (in both cases using the same file name of a file

>>>>> that is already

>>>>> on

>>>>> the disk)

>>>>>

>>>>>> When you change the filename it writes the new file with

>>>>>> the new name but does not mark the old one for deletion.

>>>>>

>>>>> But in both cases above, we're NOT changing the filename.

>>>>>

>>>>>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>>>>>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>>>>>> Colin Barnhorst wrote:

>>>>>>>> It is how the two commands have always worked and why when you

>>>>>>>> use the

>>>>>>>> Save As command you are prompted if the file already exists as

>>>>>>>> to whether

>>>>>>>> or not you want to replace the existing one.

>>>>>>>>

>>>>>>>> The Save command only saves the changes to the file and saves

>>>>>>>> them in

>>>>>>>> the next available place large enough for the fragment. That

>>>>>>>> can be anywhere

>>>>>>>> on the drive. The file manager then records a link and the

>>>>>>>> next time

>>>>>>>> the

>>>>>>>> file is read into memory the file system follows the links

>>>>>>>> until all of

>>>>>>>> the file is in memory. That's what causes the heads to

>>>>>>>> sometimes skip

>>>>>>>> all over the place when loading the file and why it takes a

>>>>>>>> long time

>>>>>>>> and a lot of disk activity to load some files.

>>>>>>>>

>>>>>>>> If the file is a series of fragments scattered all over the

>>>>>>>> drive then

>>>>>>>> selecting Save As will write a new, contiguous copy in a

>>>>>>>> location that

>>>>>>>> can hold it, thus eliminating the need for links. The file

>>>>>>>> manager then

>>>>>>>> marks the old pieces as available and the next defrag will

>>>>>>>> consolidate

>>>>>>>> these pieces of free space into larger contiguous areas

>>>>>>>> available for

>>>>>>>> writes. In the meantime disk performance improves because the

>>>>>>>> drive heads are moving far less, shortening access time and

>>>>>>>> reducing wear and

>>>>>>>> tear. There is no downside that I know of to using Save As

>>>>>>>> except the

>>>>>>>> additional step of confirming the "overwrite". No overwrite

>>>>>>>> takes place,

>>>>>>>> of course, since it is a new write. "Overwrite" is just an

>>>>>>>> anecdotal

>>>>>>>> descriptor for what really happens.

>>>>>>>>

>>>>>>>> This is a very old computer tip that is still valid. If you

>>>>>>>> search the

>>>>>>>> web though you will see explanations of the difference between

>>>>>>>> the two

>>>>>>>> commands as simply being that Save As offers the opportunity to

>>>>>>>> create

>>>>>>>> a

>>>>>>>> new copy while keeping the old one by changing the file name.

>>>>>>>> That is

>>>>>>>> one of the reasons to sometimes use Save As but by no means

>>>>>>>> the most useful IMHO.

>>>>>>>>

>>>>>>>> It is understanding what the Save command does NOT do that is

>>>>>>>> the key.

>>>>>>>> It does not save the entire file, but only the changes from the

>>>>>>>> current

>>>>>>>> session. These are not written into the existing file but in

>>>>>>>> a new location large enough to hold the changes.

>>>>>>>>

>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>>>>>> But see, if he removes and deletes the file, and then runs

>>>>>>>>> defrag, there

>>>>>>>>> won't be much there to defrag so it will be fast, and then

>>>>>>>>> when he copies it back *to a freshly defragmented drive*, it

>>>>>>>>> should be stored

>>>>>>>>> there in contiguous sectors, right?

>>>>>>>>>

>>>>>>>>> ALSO:

>>>>>>>>> "Save as" always stores a contiguous file? And "save"

>>>>>>>>> doesn't? I didn't know that. Do you have some reference

>>>>>>>>> article on that? (I'm

>>>>>>>>> assuming we're not talking about just overwriting an existing

>>>>>>>>> file when

>>>>>>>>> using Save, which may be different)

>>>>>>>>>

>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>> It doesn't matter how he does it because a heavily fragged

>>>>>>>>>> drive will

>>>>>>>>>> suffer far more wear and tear from head movement than any

>>>>>>>>>> defragging

>>>>>>>>>> operation will

>>>>>>>>>> ever cause. The easiest tip for reducing fragmentation in

>>>>>>>>>> the first

>>>>>>>>>> place

>>>>>>>>>> is to avoid using the Save command and stick to Save As. That

>>>>>>>>>> way the

>>>>>>>>>> new or edited file is always contiguous.

>>>>>>>>>>

>>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in

>>>>>>>>>> message news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>>>>>> Probably be less and wear and tear (and faster!!) to do it

>>>>>>>>>>> the way

>>>>>>>>>>> Gerry mentioned, however.

>>>>>>>>>>>

>>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper

>>>>>>>>>>>> and letting

>>>>>>>>>>>> it defrag the file. You can uninstall the software

>>>>>>>>>>>> afterwards. Either

>>>>>>>>>>>> of those defraggers are excellent at this particular type

>>>>>>>>>>>> of defragging.

>>>>>>>>>>>>

>>>>>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>>>>>> Hi:

>>>>>>>>>>>>>

>>>>>>>>>>>>> I had a file that was over 13BG in size and the Windows

>>>>>>>>>>>>> defrag process

>>>>>>>>>>>>> went fine defragging the file per se. However, when the

>>>>>>>>>>>>> defrag process tried

>>>>>>>>>>>>> to move this large file it always hung up at 3%. As long

>>>>>>>>>>>>> as the file itself

>>>>>>>>>>>>> was being defragged everything was OK, but when it came to

>>>>>>>>>>>>> trying

>>>>>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>>>>>

>>>>>>>>>>>>> Does anyone have a solution to defragging a large file

>>>>>>>>>>>>> of this size

>>>>>>>>>>>>> within Windows XP?

>>>>>>>>>>>>>

>>>>>>>>>>>>> Thanks

>>>>>>>>>

>>>>>>>>>

>>>>>>>>

>>>>>>> If you don't change the file name, I would think "save as"

>>>>>>> would work the

>>>>>>> same way as "save." If you do change the file name, yes, I'd

>>>>>>> expect a contiguous file to be created. However, Save is a much

>>>>>>> faster operation,

>>>>>>> Ctrl-S, with no dialog box to fill out.

>>>>>>>

>>>>>>> Bill

Guest Bill in Co.
Posted

Re: Problem Defragging Large File

 

Cite, please?

 

Colin Barnhorst wrote:

> Save As saves a contiguous file in a new location. Save saves only the

> changes in a new location.

>

> "Bill in Co." <not_really_here@earthlink.net> wrote in message

> news:%23KEFfrKuIHA.748@TK2MSFTNGP05.phx.gbl...

>> I don't think that's true (that "Save As" saves in a new location, and

>> Save

>> doesn't). In either case, if the file exists, it will be overwritten in

>> the same location(s), to the best of my knowledge (meaning it will be

>> fragmented, too, since the operating system just looks for free

>> clusters).

>>

>> Colin Barnhorst wrote:

>>> Save As doesn't save over it. It saves in a new location regardless of

>>> whether you give it a new filename or not. The difference is whether or

>>> not

>>> the old copy stays (if you give a new name) or is marked for deletion.

>>>

>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>> news:eI$K%23bJuIHA.4876@TK2MSFTNGP02.phx.gbl...

>>>> Actually, I'm pretty certain I was right the first time. There is

>>>> NO

>>>> difference between using "Save" and "Save As", EXCEPT for allowing for

>>>> a

>>>> different filename.

>>>>

>>>> If the file is already there and fragmented, and you save over it

>>>> (either

>>>> way!), it will STAY fragmented.

>>>>

>>>> If the file isn't there, and you save it, it makes no difference which

>>>> way

>>>> you save it.

>>>>

>>>> If I'm wrong, show me the site supporting that.

>>>>

>>>> And the fact that the operating system marks the first cluster to

>>>> indicate

>>>> the file is deleted has nothing to do with this *specific* discussion.

>>>>

>>>> Bill in Co. wrote:

>>>>> Colin Barnhorst wrote:

>>>>>> Save As always saves the whole file. When you confirm usage of the

>>>>>> existing

>>>>>> file name it still writes a fresh, contiguous copy file and marks the

>>>>>> old

>>>>>> one for deletion.

>>>>>

>>>>> Are you sure? And you're also saying that just using SAVE will NOT

>>>>> do

>>>>> that? (in both cases using the same file name of a file that is

>>>>> already

>>>>> on

>>>>> the disk)

>>>>>

>>>>>> When you change the filename it writes the new file with

>>>>>> the new name but does not mark the old one for deletion.

>>>>>

>>>>> But in both cases above, we're NOT changing the filename.

>>>>>

>>>>>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>>>>>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>>>>>> Colin Barnhorst wrote:

>>>>>>>> It is how the two commands have always worked and why when you use

>>>>>>>> the

>>>>>>>> Save As command you are prompted if the file already exists as to

>>>>>>>> whether

>>>>>>>> or not you want to replace the existing one.

>>>>>>>>

>>>>>>>> The Save command only saves the changes to the file and saves them

>>>>>>>> in

>>>>>>>> the next available place large enough for the fragment. That can

>>>>>>>> be

>>>>>>>> anywhere

>>>>>>>> on the drive. The file manager then records a link and the next

>>>>>>>> time

>>>>>>>> the

>>>>>>>> file is read into memory the file system follows the links until

>>>>>>>> all

>>>>>>>> of

>>>>>>>> the file is in memory. That's what causes the heads to sometimes

>>>>>>>> skip

>>>>>>>> all over the place when loading the file and why it takes a long

>>>>>>>> time

>>>>>>>> and a lot of disk activity to load some files.

>>>>>>>>

>>>>>>>> If the file is a series of fragments scattered all over the drive

>>>>>>>> then

>>>>>>>> selecting Save As will write a new, contiguous copy in a location

>>>>>>>> that

>>>>>>>> can hold it, thus eliminating the need for links. The file manager

>>>>>>>> then

>>>>>>>> marks the old pieces as available and the next defrag will

>>>>>>>> consolidate

>>>>>>>> these pieces of free space into larger contiguous areas available

>>>>>>>> for

>>>>>>>> writes. In the meantime disk performance improves because the

>>>>>>>> drive

>>>>>>>> heads are moving far less, shortening access time and reducing wear

>>>>>>>> and

>>>>>>>> tear. There is no downside that I know of to using Save As except

>>>>>>>> the

>>>>>>>> additional step of confirming the "overwrite". No overwrite takes

>>>>>>>> place,

>>>>>>>> of course, since it is a new write. "Overwrite" is just an

>>>>>>>> anecdotal

>>>>>>>> descriptor for what really happens.

>>>>>>>>

>>>>>>>> This is a very old computer tip that is still valid. If you search

>>>>>>>> the

>>>>>>>> web though you will see explanations of the difference between the

>>>>>>>> two

>>>>>>>> commands as simply being that Save As offers the opportunity to

>>>>>>>> create

>>>>>>>> a

>>>>>>>> new copy while keeping the old one by changing the file name. That

>>>>>>>> is

>>>>>>>> one of the reasons to sometimes use Save As but by no means the

>>>>>>>> most

>>>>>>>> useful IMHO.

>>>>>>>>

>>>>>>>> It is understanding what the Save command does NOT do that is the

>>>>>>>> key.

>>>>>>>> It does not save the entire file, but only the changes from the

>>>>>>>> current

>>>>>>>> session. These are not written into the existing file but in a new

>>>>>>>> location large enough to hold the changes.

>>>>>>>>

>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>>>>>> But see, if he removes and deletes the file, and then runs defrag,

>>>>>>>>> there

>>>>>>>>> won't be much there to defrag so it will be fast, and then when he

>>>>>>>>> copies it back *to a freshly defragmented drive*, it should be

>>>>>>>>> stored

>>>>>>>>> there in contiguous sectors, right?

>>>>>>>>>

>>>>>>>>> ALSO:

>>>>>>>>> "Save as" always stores a contiguous file? And "save" doesn't?

>>>>>>>>> I

>>>>>>>>> didn't know that. Do you have some reference article on that?

>>>>>>>>> (I'm

>>>>>>>>> assuming we're not talking about just overwriting an existing file

>>>>>>>>> when

>>>>>>>>> using Save, which may be different)

>>>>>>>>>

>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>> It doesn't matter how he does it because a heavily fragged drive

>>>>>>>>>> will

>>>>>>>>>> suffer far more wear and tear from head movement than any

>>>>>>>>>> defragging

>>>>>>>>>> operation will

>>>>>>>>>> ever cause. The easiest tip for reducing fragmentation in the

>>>>>>>>>> first

>>>>>>>>>> place

>>>>>>>>>> is to avoid using the Save command and stick to Save As. That

>>>>>>>>>> way

>>>>>>>>>> the

>>>>>>>>>> new or edited file is always contiguous.

>>>>>>>>>>

>>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>>>>> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>>>>>> Probably be less and wear and tear (and faster!!) to do it the

>>>>>>>>>>> way

>>>>>>>>>>> Gerry mentioned, however.

>>>>>>>>>>>

>>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper and

>>>>>>>>>>>> letting

>>>>>>>>>>>> it defrag the file. You can uninstall the software afterwards.

>>>>>>>>>>>> Either

>>>>>>>>>>>> of those defraggers are excellent at this particular type of

>>>>>>>>>>>> defragging.

>>>>>>>>>>>>

>>>>>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>>>>>> Hi:

>>>>>>>>>>>>>

>>>>>>>>>>>>> I had a file that was over 13BG in size and the Windows

>>>>>>>>>>>>> defrag

>>>>>>>>>>>>> process

>>>>>>>>>>>>> went fine defragging the file per se. However, when the defrag

>>>>>>>>>>>>> process tried

>>>>>>>>>>>>> to move this large file it always hung up at 3%. As long as

>>>>>>>>>>>>> the

>>>>>>>>>>>>> file itself

>>>>>>>>>>>>> was being defragged everything was OK, but when it came to

>>>>>>>>>>>>> trying

>>>>>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>>>>>

>>>>>>>>>>>>> Does anyone have a solution to defragging a large file of

>>>>>>>>>>>>> this

>>>>>>>>>>>>> size

>>>>>>>>>>>>> within Windows XP?

>>>>>>>>>>>>>

>>>>>>>>>>>>> Thanks

>>>>>>>>>

>>>>>>>>>

>>>>>>>>

>>>>>>> If you don't change the file name, I would think "save as" would

>>>>>>> work

>>>>>>> the

>>>>>>> same way as "save." If you do change the file name, yes, I'd expect

>>>>>>> a

>>>>>>> contiguous file to be created. However, Save is a much faster

>>>>>>> operation,

>>>>>>> Ctrl-S, with no dialog box to fill out.

>>>>>>>

>>>>>>> Bill

Guest Bill in Co.
Posted

Re: Problem Defragging Large File

 

(I'm not even sure that is necessarily true, either).

 

Gerry wrote:

> Colin

>

> What you say about Save As depends on how large the file is and whether

> the next available free disk space is of sufficient size to accomodate

> the file.

>

> --

>

>

>

> Hope this helps.

>

> Gerry

> ~~~~

> FCA

> Stourport, England

> Enquire, plan and execute

> ~~~~~~~~~~~~~~~~~~~

>

> Colin Barnhorst wrote:

>> Save As saves a contiguous file in a new location. Save saves only

>> the changes in a new location.

>>

>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>> news:%23KEFfrKuIHA.748@TK2MSFTNGP05.phx.gbl...

>>> I don't think that's true (that "Save As" saves in a new location,

>>> and Save doesn't). In either case, if the file exists, it will be

>>> overwritten in the same location(s), to the best of my knowledge

>>> (meaning it will be fragmented, too, since the operating system just

>>> looks for free clusters). Colin Barnhorst wrote:

>>>> Save As doesn't save over it. It saves in a new location

>>>> regardless of whether you give it a new filename or not. The

>>>> difference is whether or not

>>>> the old copy stays (if you give a new name) or is marked for

>>>> deletion. "Bill in Co." <not_really_here@earthlink.net> wrote in

>>>> message

>>>> news:eI$K%23bJuIHA.4876@TK2MSFTNGP02.phx.gbl...

>>>>> Actually, I'm pretty certain I was right the first time. There

>>>>> is NO difference between using "Save" and "Save As", EXCEPT for

>>>>> allowing for a different filename.

>>>>>

>>>>> If the file is already there and fragmented, and you save over it

>>>>> (either

>>>>> way!), it will STAY fragmented.

>>>>>

>>>>> If the file isn't there, and you save it, it makes no difference

>>>>> which way

>>>>> you save it.

>>>>>

>>>>> If I'm wrong, show me the site supporting that.

>>>>>

>>>>> And the fact that the operating system marks the first cluster to

>>>>> indicate

>>>>> the file is deleted has nothing to do with this *specific*

>>>>> discussion. Bill in Co. wrote:

>>>>>> Colin Barnhorst wrote:

>>>>>>> Save As always saves the whole file. When you confirm usage of

>>>>>>> the existing

>>>>>>> file name it still writes a fresh, contiguous copy file and

>>>>>>> marks the old

>>>>>>> one for deletion.

>>>>>>

>>>>>> Are you sure? And you're also saying that just using SAVE will

>>>>>> NOT do that? (in both cases using the same file name of a file

>>>>>> that is already

>>>>>> on

>>>>>> the disk)

>>>>>>

>>>>>>> When you change the filename it writes the new file with

>>>>>>> the new name but does not mark the old one for deletion.

>>>>>>

>>>>>> But in both cases above, we're NOT changing the filename.

>>>>>>

>>>>>>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>>>>>>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>> It is how the two commands have always worked and why when you

>>>>>>>>> use the

>>>>>>>>> Save As command you are prompted if the file already exists as

>>>>>>>>> to whether

>>>>>>>>> or not you want to replace the existing one.

>>>>>>>>>

>>>>>>>>> The Save command only saves the changes to the file and saves

>>>>>>>>> them in

>>>>>>>>> the next available place large enough for the fragment. That

>>>>>>>>> can be anywhere

>>>>>>>>> on the drive. The file manager then records a link and the

>>>>>>>>> next time

>>>>>>>>> the

>>>>>>>>> file is read into memory the file system follows the links

>>>>>>>>> until all of

>>>>>>>>> the file is in memory. That's what causes the heads to

>>>>>>>>> sometimes skip

>>>>>>>>> all over the place when loading the file and why it takes a

>>>>>>>>> long time

>>>>>>>>> and a lot of disk activity to load some files.

>>>>>>>>>

>>>>>>>>> If the file is a series of fragments scattered all over the

>>>>>>>>> drive then

>>>>>>>>> selecting Save As will write a new, contiguous copy in a

>>>>>>>>> location that

>>>>>>>>> can hold it, thus eliminating the need for links. The file

>>>>>>>>> manager then

>>>>>>>>> marks the old pieces as available and the next defrag will

>>>>>>>>> consolidate

>>>>>>>>> these pieces of free space into larger contiguous areas

>>>>>>>>> available for

>>>>>>>>> writes. In the meantime disk performance improves because the

>>>>>>>>> drive heads are moving far less, shortening access time and

>>>>>>>>> reducing wear and

>>>>>>>>> tear. There is no downside that I know of to using Save As

>>>>>>>>> except the

>>>>>>>>> additional step of confirming the "overwrite". No overwrite

>>>>>>>>> takes place,

>>>>>>>>> of course, since it is a new write. "Overwrite" is just an

>>>>>>>>> anecdotal

>>>>>>>>> descriptor for what really happens.

>>>>>>>>>

>>>>>>>>> This is a very old computer tip that is still valid. If you

>>>>>>>>> search the

>>>>>>>>> web though you will see explanations of the difference between

>>>>>>>>> the two

>>>>>>>>> commands as simply being that Save As offers the opportunity to

>>>>>>>>> create

>>>>>>>>> a

>>>>>>>>> new copy while keeping the old one by changing the file name.

>>>>>>>>> That is

>>>>>>>>> one of the reasons to sometimes use Save As but by no means

>>>>>>>>> the most useful IMHO.

>>>>>>>>>

>>>>>>>>> It is understanding what the Save command does NOT do that is

>>>>>>>>> the key.

>>>>>>>>> It does not save the entire file, but only the changes from the

>>>>>>>>> current

>>>>>>>>> session. These are not written into the existing file but in

>>>>>>>>> a new location large enough to hold the changes.

>>>>>>>>>

>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>>>>>>> But see, if he removes and deletes the file, and then runs

>>>>>>>>>> defrag, there

>>>>>>>>>> won't be much there to defrag so it will be fast, and then

>>>>>>>>>> when he copies it back *to a freshly defragmented drive*, it

>>>>>>>>>> should be stored

>>>>>>>>>> there in contiguous sectors, right?

>>>>>>>>>>

>>>>>>>>>> ALSO:

>>>>>>>>>> "Save as" always stores a contiguous file? And "save"

>>>>>>>>>> doesn't? I didn't know that. Do you have some reference

>>>>>>>>>> article on that? (I'm

>>>>>>>>>> assuming we're not talking about just overwriting an existing

>>>>>>>>>> file when

>>>>>>>>>> using Save, which may be different)

>>>>>>>>>>

>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>> It doesn't matter how he does it because a heavily fragged

>>>>>>>>>>> drive will

>>>>>>>>>>> suffer far more wear and tear from head movement than any

>>>>>>>>>>> defragging

>>>>>>>>>>> operation will

>>>>>>>>>>> ever cause. The easiest tip for reducing fragmentation in

>>>>>>>>>>> the first

>>>>>>>>>>> place

>>>>>>>>>>> is to avoid using the Save command and stick to Save As. That

>>>>>>>>>>> way the

>>>>>>>>>>> new or edited file is always contiguous.

>>>>>>>>>>>

>>>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in

>>>>>>>>>>> message news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>>>>>>> Probably be less and wear and tear (and faster!!) to do it

>>>>>>>>>>>> the way

>>>>>>>>>>>> Gerry mentioned, however.

>>>>>>>>>>>>

>>>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper

>>>>>>>>>>>>> and letting

>>>>>>>>>>>>> it defrag the file. You can uninstall the software

>>>>>>>>>>>>> afterwards. Either

>>>>>>>>>>>>> of those defraggers are excellent at this particular type

>>>>>>>>>>>>> of defragging.

>>>>>>>>>>>>>

>>>>>>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>>>>>>> Hi:

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> I had a file that was over 13BG in size and the Windows

>>>>>>>>>>>>>> defrag process

>>>>>>>>>>>>>> went fine defragging the file per se. However, when the

>>>>>>>>>>>>>> defrag process tried

>>>>>>>>>>>>>> to move this large file it always hung up at 3%. As long

>>>>>>>>>>>>>> as the file itself

>>>>>>>>>>>>>> was being defragged everything was OK, but when it came to

>>>>>>>>>>>>>> trying

>>>>>>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> Does anyone have a solution to defragging a large file

>>>>>>>>>>>>>> of this size

>>>>>>>>>>>>>> within Windows XP?

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> Thanks

>>>>>>>>>>

>>>>>>>>>>

>>>>>>>>>

>>>>>>>> If you don't change the file name, I would think "save as"

>>>>>>>> would work the

>>>>>>>> same way as "save." If you do change the file name, yes, I'd

>>>>>>>> expect a contiguous file to be created. However, Save is a much

>>>>>>>> faster operation,

>>>>>>>> Ctrl-S, with no dialog box to fill out.

>>>>>>>>

>>>>>>>> Bill

Guest Colin Barnhorst
Posted

Re: Problem Defragging Large File

 

Save As will always create a complete new file in a new location.

 

As far as I know the operation is designed to be quick and be gone, whether

Save or Save As. I don't think the file manager messes around with the

existing file. There are too many variables and it would take too long. In

any case it does not insert data into an existing file. It either saves the

changes and updates the file structure data (Save) or it saves a new copy of

the file and marks the old for deletion if a new file name, path, or type is

not specified (Save As).

 

The Save command is not designed to analyse the file, find an insertion

point, open, insert, close, etc. It is a quick and dirty operation.

 

Open uses the links recorded by Save to stitch the file fragments back

together in the correct sequence when the file is again called into memory.

This sewing machine effect is most noticeable when the drive heads start

tracking all over the drive to get all the pieces.

 

"Gerry" <gerry@nospam.com> wrote in message

news:eHa1rMRuIHA.1936@TK2MSFTNGP04.phx.gbl...

> Colin

>

> What you say about Save As depends on how large the file is and whether

> the next available free disk space is of sufficient size to accomodate the

> file.

>

> --

>

>

>

> Hope this helps.

>

> Gerry

> ~~~~

> FCA

> Stourport, England

> Enquire, plan and execute

> ~~~~~~~~~~~~~~~~~~~

>

> Colin Barnhorst wrote:

>> Save As saves a contiguous file in a new location. Save saves only

>> the changes in a new location.

>>

>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>> news:%23KEFfrKuIHA.748@TK2MSFTNGP05.phx.gbl...

>>> I don't think that's true (that "Save As" saves in a new location,

>>> and Save doesn't). In either case, if the file exists, it will be

>>> overwritten in the same location(s), to the best of my knowledge

>>> (meaning it will be fragmented, too, since the operating system just

>>> looks for free clusters). Colin Barnhorst wrote:

>>>> Save As doesn't save over it. It saves in a new location

>>>> regardless of whether you give it a new filename or not. The

>>>> difference is whether or not

>>>> the old copy stays (if you give a new name) or is marked for

>>>> deletion. "Bill in Co." <not_really_here@earthlink.net> wrote in

>>>> message

>>>> news:eI$K%23bJuIHA.4876@TK2MSFTNGP02.phx.gbl...

>>>>> Actually, I'm pretty certain I was right the first time. There

>>>>> is NO difference between using "Save" and "Save As", EXCEPT for

>>>>> allowing for a different filename.

>>>>>

>>>>> If the file is already there and fragmented, and you save over it

>>>>> (either

>>>>> way!), it will STAY fragmented.

>>>>>

>>>>> If the file isn't there, and you save it, it makes no difference

>>>>> which way

>>>>> you save it.

>>>>>

>>>>> If I'm wrong, show me the site supporting that.

>>>>>

>>>>> And the fact that the operating system marks the first cluster to

>>>>> indicate

>>>>> the file is deleted has nothing to do with this *specific*

>>>>> discussion. Bill in Co. wrote:

>>>>>> Colin Barnhorst wrote:

>>>>>>> Save As always saves the whole file. When you confirm usage of

>>>>>>> the existing

>>>>>>> file name it still writes a fresh, contiguous copy file and

>>>>>>> marks the old

>>>>>>> one for deletion.

>>>>>>

>>>>>> Are you sure? And you're also saying that just using SAVE will

>>>>>> NOT do that? (in both cases using the same file name of a file

>>>>>> that is already

>>>>>> on

>>>>>> the disk)

>>>>>>

>>>>>>> When you change the filename it writes the new file with

>>>>>>> the new name but does not mark the old one for deletion.

>>>>>>

>>>>>> But in both cases above, we're NOT changing the filename.

>>>>>>

>>>>>>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>>>>>>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>> It is how the two commands have always worked and why when you

>>>>>>>>> use the

>>>>>>>>> Save As command you are prompted if the file already exists as

>>>>>>>>> to whether

>>>>>>>>> or not you want to replace the existing one.

>>>>>>>>>

>>>>>>>>> The Save command only saves the changes to the file and saves

>>>>>>>>> them in

>>>>>>>>> the next available place large enough for the fragment. That

>>>>>>>>> can be anywhere

>>>>>>>>> on the drive. The file manager then records a link and the

>>>>>>>>> next time

>>>>>>>>> the

>>>>>>>>> file is read into memory the file system follows the links

>>>>>>>>> until all of

>>>>>>>>> the file is in memory. That's what causes the heads to

>>>>>>>>> sometimes skip

>>>>>>>>> all over the place when loading the file and why it takes a

>>>>>>>>> long time

>>>>>>>>> and a lot of disk activity to load some files.

>>>>>>>>>

>>>>>>>>> If the file is a series of fragments scattered all over the

>>>>>>>>> drive then

>>>>>>>>> selecting Save As will write a new, contiguous copy in a

>>>>>>>>> location that

>>>>>>>>> can hold it, thus eliminating the need for links. The file

>>>>>>>>> manager then

>>>>>>>>> marks the old pieces as available and the next defrag will

>>>>>>>>> consolidate

>>>>>>>>> these pieces of free space into larger contiguous areas

>>>>>>>>> available for

>>>>>>>>> writes. In the meantime disk performance improves because the

>>>>>>>>> drive heads are moving far less, shortening access time and

>>>>>>>>> reducing wear and

>>>>>>>>> tear. There is no downside that I know of to using Save As

>>>>>>>>> except the

>>>>>>>>> additional step of confirming the "overwrite". No overwrite

>>>>>>>>> takes place,

>>>>>>>>> of course, since it is a new write. "Overwrite" is just an

>>>>>>>>> anecdotal

>>>>>>>>> descriptor for what really happens.

>>>>>>>>>

>>>>>>>>> This is a very old computer tip that is still valid. If you

>>>>>>>>> search the

>>>>>>>>> web though you will see explanations of the difference between

>>>>>>>>> the two

>>>>>>>>> commands as simply being that Save As offers the opportunity to

>>>>>>>>> create

>>>>>>>>> a

>>>>>>>>> new copy while keeping the old one by changing the file name. That

>>>>>>>>> is

>>>>>>>>> one of the reasons to sometimes use Save As but by no means

>>>>>>>>> the most useful IMHO.

>>>>>>>>>

>>>>>>>>> It is understanding what the Save command does NOT do that is

>>>>>>>>> the key.

>>>>>>>>> It does not save the entire file, but only the changes from the

>>>>>>>>> current

>>>>>>>>> session. These are not written into the existing file but in

>>>>>>>>> a new location large enough to hold the changes.

>>>>>>>>>

>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>>>>>>> But see, if he removes and deletes the file, and then runs

>>>>>>>>>> defrag, there

>>>>>>>>>> won't be much there to defrag so it will be fast, and then

>>>>>>>>>> when he copies it back *to a freshly defragmented drive*, it

>>>>>>>>>> should be stored

>>>>>>>>>> there in contiguous sectors, right?

>>>>>>>>>>

>>>>>>>>>> ALSO:

>>>>>>>>>> "Save as" always stores a contiguous file? And "save"

>>>>>>>>>> doesn't? I didn't know that. Do you have some reference

>>>>>>>>>> article on that? (I'm

>>>>>>>>>> assuming we're not talking about just overwriting an existing

>>>>>>>>>> file when

>>>>>>>>>> using Save, which may be different)

>>>>>>>>>>

>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>> It doesn't matter how he does it because a heavily fragged

>>>>>>>>>>> drive will

>>>>>>>>>>> suffer far more wear and tear from head movement than any

>>>>>>>>>>> defragging

>>>>>>>>>>> operation will

>>>>>>>>>>> ever cause. The easiest tip for reducing fragmentation in

>>>>>>>>>>> the first

>>>>>>>>>>> place

>>>>>>>>>>> is to avoid using the Save command and stick to Save As. That

>>>>>>>>>>> way the

>>>>>>>>>>> new or edited file is always contiguous.

>>>>>>>>>>>

>>>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in

>>>>>>>>>>> message news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>>>>>>> Probably be less and wear and tear (and faster!!) to do it

>>>>>>>>>>>> the way

>>>>>>>>>>>> Gerry mentioned, however.

>>>>>>>>>>>>

>>>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper

>>>>>>>>>>>>> and letting

>>>>>>>>>>>>> it defrag the file. You can uninstall the software

>>>>>>>>>>>>> afterwards. Either

>>>>>>>>>>>>> of those defraggers are excellent at this particular type

>>>>>>>>>>>>> of defragging.

>>>>>>>>>>>>>

>>>>>>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>>>>>>> Hi:

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> I had a file that was over 13BG in size and the Windows

>>>>>>>>>>>>>> defrag process

>>>>>>>>>>>>>> went fine defragging the file per se. However, when the

>>>>>>>>>>>>>> defrag process tried

>>>>>>>>>>>>>> to move this large file it always hung up at 3%. As long

>>>>>>>>>>>>>> as the file itself

>>>>>>>>>>>>>> was being defragged everything was OK, but when it came to

>>>>>>>>>>>>>> trying

>>>>>>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> Does anyone have a solution to defragging a large file

>>>>>>>>>>>>>> of this size

>>>>>>>>>>>>>> within Windows XP?

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> Thanks

>>>>>>>>>>

>>>>>>>>>>

>>>>>>>>>

>>>>>>>> If you don't change the file name, I would think "save as"

>>>>>>>> would work the

>>>>>>>> same way as "save." If you do change the file name, yes, I'd

>>>>>>>> expect a contiguous file to be created. However, Save is a much

>>>>>>>> faster operation,

>>>>>>>> Ctrl-S, with no dialog box to fill out.

>>>>>>>>

>>>>>>>> Bill

>

>

Guest Colin Barnhorst
Posted

Re: Problem Defragging Large File

 

The detailed descriptions are in the API calls (I think) which I have never

used. As I recall, things like PutFile something or other. I scanned some

TechNet stuff once, but not my cup of tea. It is all there but that is not

where I first learned about it. Bop over to TechNet and look for a likely

forum and ask.

 

"Bill in Co." <not_really_here@earthlink.net> wrote in message

news:udb$5uRuIHA.552@TK2MSFTNGP06.phx.gbl...

> Cite, please?

>

> Colin Barnhorst wrote:

>> Save As saves a contiguous file in a new location. Save saves only the

>> changes in a new location.

>>

>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>> news:%23KEFfrKuIHA.748@TK2MSFTNGP05.phx.gbl...

>>> I don't think that's true (that "Save As" saves in a new location, and

>>> Save

>>> doesn't). In either case, if the file exists, it will be overwritten

>>> in

>>> the same location(s), to the best of my knowledge (meaning it will be

>>> fragmented, too, since the operating system just looks for free

>>> clusters).

>>>

>>> Colin Barnhorst wrote:

>>>> Save As doesn't save over it. It saves in a new location regardless of

>>>> whether you give it a new filename or not. The difference is whether

>>>> or

>>>> not

>>>> the old copy stays (if you give a new name) or is marked for deletion.

>>>>

>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>> news:eI$K%23bJuIHA.4876@TK2MSFTNGP02.phx.gbl...

>>>>> Actually, I'm pretty certain I was right the first time. There is

>>>>> NO

>>>>> difference between using "Save" and "Save As", EXCEPT for allowing for

>>>>> a

>>>>> different filename.

>>>>>

>>>>> If the file is already there and fragmented, and you save over it

>>>>> (either

>>>>> way!), it will STAY fragmented.

>>>>>

>>>>> If the file isn't there, and you save it, it makes no difference which

>>>>> way

>>>>> you save it.

>>>>>

>>>>> If I'm wrong, show me the site supporting that.

>>>>>

>>>>> And the fact that the operating system marks the first cluster to

>>>>> indicate

>>>>> the file is deleted has nothing to do with this *specific* discussion.

>>>>>

>>>>> Bill in Co. wrote:

>>>>>> Colin Barnhorst wrote:

>>>>>>> Save As always saves the whole file. When you confirm usage of the

>>>>>>> existing

>>>>>>> file name it still writes a fresh, contiguous copy file and marks

>>>>>>> the

>>>>>>> old

>>>>>>> one for deletion.

>>>>>>

>>>>>> Are you sure? And you're also saying that just using SAVE will NOT

>>>>>> do

>>>>>> that? (in both cases using the same file name of a file that is

>>>>>> already

>>>>>> on

>>>>>> the disk)

>>>>>>

>>>>>>> When you change the filename it writes the new file with

>>>>>>> the new name but does not mark the old one for deletion.

>>>>>>

>>>>>> But in both cases above, we're NOT changing the filename.

>>>>>>

>>>>>>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>>>>>>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>> It is how the two commands have always worked and why when you use

>>>>>>>>> the

>>>>>>>>> Save As command you are prompted if the file already exists as to

>>>>>>>>> whether

>>>>>>>>> or not you want to replace the existing one.

>>>>>>>>>

>>>>>>>>> The Save command only saves the changes to the file and saves them

>>>>>>>>> in

>>>>>>>>> the next available place large enough for the fragment. That can

>>>>>>>>> be

>>>>>>>>> anywhere

>>>>>>>>> on the drive. The file manager then records a link and the next

>>>>>>>>> time

>>>>>>>>> the

>>>>>>>>> file is read into memory the file system follows the links until

>>>>>>>>> all

>>>>>>>>> of

>>>>>>>>> the file is in memory. That's what causes the heads to sometimes

>>>>>>>>> skip

>>>>>>>>> all over the place when loading the file and why it takes a long

>>>>>>>>> time

>>>>>>>>> and a lot of disk activity to load some files.

>>>>>>>>>

>>>>>>>>> If the file is a series of fragments scattered all over the drive

>>>>>>>>> then

>>>>>>>>> selecting Save As will write a new, contiguous copy in a location

>>>>>>>>> that

>>>>>>>>> can hold it, thus eliminating the need for links. The file

>>>>>>>>> manager

>>>>>>>>> then

>>>>>>>>> marks the old pieces as available and the next defrag will

>>>>>>>>> consolidate

>>>>>>>>> these pieces of free space into larger contiguous areas available

>>>>>>>>> for

>>>>>>>>> writes. In the meantime disk performance improves because the

>>>>>>>>> drive

>>>>>>>>> heads are moving far less, shortening access time and reducing

>>>>>>>>> wear

>>>>>>>>> and

>>>>>>>>> tear. There is no downside that I know of to using Save As except

>>>>>>>>> the

>>>>>>>>> additional step of confirming the "overwrite". No overwrite takes

>>>>>>>>> place,

>>>>>>>>> of course, since it is a new write. "Overwrite" is just an

>>>>>>>>> anecdotal

>>>>>>>>> descriptor for what really happens.

>>>>>>>>>

>>>>>>>>> This is a very old computer tip that is still valid. If you

>>>>>>>>> search

>>>>>>>>> the

>>>>>>>>> web though you will see explanations of the difference between the

>>>>>>>>> two

>>>>>>>>> commands as simply being that Save As offers the opportunity to

>>>>>>>>> create

>>>>>>>>> a

>>>>>>>>> new copy while keeping the old one by changing the file name.

>>>>>>>>> That

>>>>>>>>> is

>>>>>>>>> one of the reasons to sometimes use Save As but by no means the

>>>>>>>>> most

>>>>>>>>> useful IMHO.

>>>>>>>>>

>>>>>>>>> It is understanding what the Save command does NOT do that is the

>>>>>>>>> key.

>>>>>>>>> It does not save the entire file, but only the changes from the

>>>>>>>>> current

>>>>>>>>> session. These are not written into the existing file but in a

>>>>>>>>> new

>>>>>>>>> location large enough to hold the changes.

>>>>>>>>>

>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>>>>>>> But see, if he removes and deletes the file, and then runs

>>>>>>>>>> defrag,

>>>>>>>>>> there

>>>>>>>>>> won't be much there to defrag so it will be fast, and then when

>>>>>>>>>> he

>>>>>>>>>> copies it back *to a freshly defragmented drive*, it should be

>>>>>>>>>> stored

>>>>>>>>>> there in contiguous sectors, right?

>>>>>>>>>>

>>>>>>>>>> ALSO:

>>>>>>>>>> "Save as" always stores a contiguous file? And "save" doesn't?

>>>>>>>>>> I

>>>>>>>>>> didn't know that. Do you have some reference article on that?

>>>>>>>>>> (I'm

>>>>>>>>>> assuming we're not talking about just overwriting an existing

>>>>>>>>>> file

>>>>>>>>>> when

>>>>>>>>>> using Save, which may be different)

>>>>>>>>>>

>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>> It doesn't matter how he does it because a heavily fragged drive

>>>>>>>>>>> will

>>>>>>>>>>> suffer far more wear and tear from head movement than any

>>>>>>>>>>> defragging

>>>>>>>>>>> operation will

>>>>>>>>>>> ever cause. The easiest tip for reducing fragmentation in the

>>>>>>>>>>> first

>>>>>>>>>>> place

>>>>>>>>>>> is to avoid using the Save command and stick to Save As. That

>>>>>>>>>>> way

>>>>>>>>>>> the

>>>>>>>>>>> new or edited file is always contiguous.

>>>>>>>>>>>

>>>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>>>>>> news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>>>>>>> Probably be less and wear and tear (and faster!!) to do it the

>>>>>>>>>>>> way

>>>>>>>>>>>> Gerry mentioned, however.

>>>>>>>>>>>>

>>>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper and

>>>>>>>>>>>>> letting

>>>>>>>>>>>>> it defrag the file. You can uninstall the software

>>>>>>>>>>>>> afterwards.

>>>>>>>>>>>>> Either

>>>>>>>>>>>>> of those defraggers are excellent at this particular type of

>>>>>>>>>>>>> defragging.

>>>>>>>>>>>>>

>>>>>>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>>>>>>> Hi:

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> I had a file that was over 13BG in size and the Windows

>>>>>>>>>>>>>> defrag

>>>>>>>>>>>>>> process

>>>>>>>>>>>>>> went fine defragging the file per se. However, when the

>>>>>>>>>>>>>> defrag

>>>>>>>>>>>>>> process tried

>>>>>>>>>>>>>> to move this large file it always hung up at 3%. As long as

>>>>>>>>>>>>>> the

>>>>>>>>>>>>>> file itself

>>>>>>>>>>>>>> was being defragged everything was OK, but when it came to

>>>>>>>>>>>>>> trying

>>>>>>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> Does anyone have a solution to defragging a large file of

>>>>>>>>>>>>>> this

>>>>>>>>>>>>>> size

>>>>>>>>>>>>>> within Windows XP?

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> Thanks

>>>>>>>>>>

>>>>>>>>>>

>>>>>>>>>

>>>>>>>> If you don't change the file name, I would think "save as" would

>>>>>>>> work

>>>>>>>> the

>>>>>>>> same way as "save." If you do change the file name, yes, I'd expect

>>>>>>>> a

>>>>>>>> contiguous file to be created. However, Save is a much faster

>>>>>>>> operation,

>>>>>>>> Ctrl-S, with no dialog box to fill out.

>>>>>>>>

>>>>>>>> Bill

>

>

Guest Bill in Co.
Posted

Re: Problem Defragging Large File

 

Colin Barnhorst wrote:

> Save As will always create a complete new file in a new location.

 

No offense, but I don't believe that is true. And so far, you haven't

shown any evidence that it is true. It really makes little sense, anyway,

when you think about it.

> As far as I know the operation is designed to be quick and be gone,

> whether

> Save or Save As. I don't think the file manager messes around with the

> existing file. There are too many variables and it would take too long.

> In

> any case it does not insert data into an existing file. It either saves

> the

> changes and updates the file structure data (Save) or it saves a new copy

> of

> the file and marks the old for deletion if a new file name, path, or type

> is

> not specified (Save As).

>

> The Save command is not designed to analyse the file, find an insertion

> point, open, insert, close, etc. It is a quick and dirty operation.

>

> Open uses the links recorded by Save to stitch the file fragments back

> together in the correct sequence when the file is again called into

> memory.

> This sewing machine effect is most noticeable when the drive heads start

> tracking all over the drive to get all the pieces.

>

> "Gerry" <gerry@nospam.com> wrote in message

> news:eHa1rMRuIHA.1936@TK2MSFTNGP04.phx.gbl...

>> Colin

>>

>> What you say about Save As depends on how large the file is and whether

>> the next available free disk space is of sufficient size to accomodate

>> the

>> file.

>>

>> --

>>

>>

>>

>> Hope this helps.

>>

>> Gerry

>> ~~~~

>> FCA

>> Stourport, England

>> Enquire, plan and execute

>> ~~~~~~~~~~~~~~~~~~~

>>

>> Colin Barnhorst wrote:

>>> Save As saves a contiguous file in a new location. Save saves only

>>> the changes in a new location.

>>>

>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>> news:%23KEFfrKuIHA.748@TK2MSFTNGP05.phx.gbl...

>>>> I don't think that's true (that "Save As" saves in a new location,

>>>> and Save doesn't). In either case, if the file exists, it will be

>>>> overwritten in the same location(s), to the best of my knowledge

>>>> (meaning it will be fragmented, too, since the operating system just

>>>> looks for free clusters). Colin Barnhorst wrote:

>>>>> Save As doesn't save over it. It saves in a new location

>>>>> regardless of whether you give it a new filename or not. The

>>>>> difference is whether or not

>>>>> the old copy stays (if you give a new name) or is marked for

>>>>> deletion. "Bill in Co." <not_really_here@earthlink.net> wrote in

>>>>> message

>>>>> news:eI$K%23bJuIHA.4876@TK2MSFTNGP02.phx.gbl...

>>>>>> Actually, I'm pretty certain I was right the first time. There

>>>>>> is NO difference between using "Save" and "Save As", EXCEPT for

>>>>>> allowing for a different filename.

>>>>>>

>>>>>> If the file is already there and fragmented, and you save over it

>>>>>> (either

>>>>>> way!), it will STAY fragmented.

>>>>>>

>>>>>> If the file isn't there, and you save it, it makes no difference

>>>>>> which way

>>>>>> you save it.

>>>>>>

>>>>>> If I'm wrong, show me the site supporting that.

>>>>>>

>>>>>> And the fact that the operating system marks the first cluster to

>>>>>> indicate

>>>>>> the file is deleted has nothing to do with this *specific*

>>>>>> discussion. Bill in Co. wrote:

>>>>>>> Colin Barnhorst wrote:

>>>>>>>> Save As always saves the whole file. When you confirm usage of

>>>>>>>> the existing

>>>>>>>> file name it still writes a fresh, contiguous copy file and

>>>>>>>> marks the old

>>>>>>>> one for deletion.

>>>>>>>

>>>>>>> Are you sure? And you're also saying that just using SAVE will

>>>>>>> NOT do that? (in both cases using the same file name of a file

>>>>>>> that is already

>>>>>>> on

>>>>>>> the disk)

>>>>>>>

>>>>>>>> When you change the filename it writes the new file with

>>>>>>>> the new name but does not mark the old one for deletion.

>>>>>>>

>>>>>>> But in both cases above, we're NOT changing the filename.

>>>>>>>

>>>>>>>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>>>>>>>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>> It is how the two commands have always worked and why when you

>>>>>>>>>> use the

>>>>>>>>>> Save As command you are prompted if the file already exists as

>>>>>>>>>> to whether

>>>>>>>>>> or not you want to replace the existing one.

>>>>>>>>>>

>>>>>>>>>> The Save command only saves the changes to the file and saves

>>>>>>>>>> them in

>>>>>>>>>> the next available place large enough for the fragment. That

>>>>>>>>>> can be anywhere

>>>>>>>>>> on the drive. The file manager then records a link and the

>>>>>>>>>> next time

>>>>>>>>>> the

>>>>>>>>>> file is read into memory the file system follows the links

>>>>>>>>>> until all of

>>>>>>>>>> the file is in memory. That's what causes the heads to

>>>>>>>>>> sometimes skip

>>>>>>>>>> all over the place when loading the file and why it takes a

>>>>>>>>>> long time

>>>>>>>>>> and a lot of disk activity to load some files.

>>>>>>>>>>

>>>>>>>>>> If the file is a series of fragments scattered all over the

>>>>>>>>>> drive then

>>>>>>>>>> selecting Save As will write a new, contiguous copy in a

>>>>>>>>>> location that

>>>>>>>>>> can hold it, thus eliminating the need for links. The file

>>>>>>>>>> manager then

>>>>>>>>>> marks the old pieces as available and the next defrag will

>>>>>>>>>> consolidate

>>>>>>>>>> these pieces of free space into larger contiguous areas

>>>>>>>>>> available for

>>>>>>>>>> writes. In the meantime disk performance improves because the

>>>>>>>>>> drive heads are moving far less, shortening access time and

>>>>>>>>>> reducing wear and

>>>>>>>>>> tear. There is no downside that I know of to using Save As

>>>>>>>>>> except the

>>>>>>>>>> additional step of confirming the "overwrite". No overwrite

>>>>>>>>>> takes place,

>>>>>>>>>> of course, since it is a new write. "Overwrite" is just an

>>>>>>>>>> anecdotal

>>>>>>>>>> descriptor for what really happens.

>>>>>>>>>>

>>>>>>>>>> This is a very old computer tip that is still valid. If you

>>>>>>>>>> search the

>>>>>>>>>> web though you will see explanations of the difference between

>>>>>>>>>> the two

>>>>>>>>>> commands as simply being that Save As offers the opportunity to

>>>>>>>>>> create

>>>>>>>>>> a

>>>>>>>>>> new copy while keeping the old one by changing the file name.

>>>>>>>>>> That

>>>>>>>>>> is

>>>>>>>>>> one of the reasons to sometimes use Save As but by no means

>>>>>>>>>> the most useful IMHO.

>>>>>>>>>>

>>>>>>>>>> It is understanding what the Save command does NOT do that is

>>>>>>>>>> the key.

>>>>>>>>>> It does not save the entire file, but only the changes from the

>>>>>>>>>> current

>>>>>>>>>> session. These are not written into the existing file but in

>>>>>>>>>> a new location large enough to hold the changes.

>>>>>>>>>>

>>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>>>>>>>>> news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>>>>>>>> But see, if he removes and deletes the file, and then runs

>>>>>>>>>>> defrag, there

>>>>>>>>>>> won't be much there to defrag so it will be fast, and then

>>>>>>>>>>> when he copies it back *to a freshly defragmented drive*, it

>>>>>>>>>>> should be stored

>>>>>>>>>>> there in contiguous sectors, right?

>>>>>>>>>>>

>>>>>>>>>>> ALSO:

>>>>>>>>>>> "Save as" always stores a contiguous file? And "save"

>>>>>>>>>>> doesn't? I didn't know that. Do you have some reference

>>>>>>>>>>> article on that? (I'm

>>>>>>>>>>> assuming we're not talking about just overwriting an existing

>>>>>>>>>>> file when

>>>>>>>>>>> using Save, which may be different)

>>>>>>>>>>>

>>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>>> It doesn't matter how he does it because a heavily fragged

>>>>>>>>>>>> drive will

>>>>>>>>>>>> suffer far more wear and tear from head movement than any

>>>>>>>>>>>> defragging

>>>>>>>>>>>> operation will

>>>>>>>>>>>> ever cause. The easiest tip for reducing fragmentation in

>>>>>>>>>>>> the first

>>>>>>>>>>>> place

>>>>>>>>>>>> is to avoid using the Save command and stick to Save As. That

>>>>>>>>>>>> way the

>>>>>>>>>>>> new or edited file is always contiguous.

>>>>>>>>>>>>

>>>>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in

>>>>>>>>>>>> message news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>>>>>>>> Probably be less and wear and tear (and faster!!) to do it

>>>>>>>>>>>>> the way

>>>>>>>>>>>>> Gerry mentioned, however.

>>>>>>>>>>>>>

>>>>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper

>>>>>>>>>>>>>> and letting

>>>>>>>>>>>>>> it defrag the file. You can uninstall the software

>>>>>>>>>>>>>> afterwards. Either

>>>>>>>>>>>>>> of those defraggers are excellent at this particular type

>>>>>>>>>>>>>> of defragging.

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>>>>>>>> Hi:

>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> I had a file that was over 13BG in size and the Windows

>>>>>>>>>>>>>>> defrag process

>>>>>>>>>>>>>>> went fine defragging the file per se. However, when the

>>>>>>>>>>>>>>> defrag process tried

>>>>>>>>>>>>>>> to move this large file it always hung up at 3%. As long

>>>>>>>>>>>>>>> as the file itself

>>>>>>>>>>>>>>> was being defragged everything was OK, but when it came to

>>>>>>>>>>>>>>> trying

>>>>>>>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> Does anyone have a solution to defragging a large file

>>>>>>>>>>>>>>> of this size

>>>>>>>>>>>>>>> within Windows XP?

>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> Thanks

>>>>>>>>>>>

>>>>>>>>>>>

>>>>>>>>>>

>>>>>>>>> If you don't change the file name, I would think "save as"

>>>>>>>>> would work the

>>>>>>>>> same way as "save." If you do change the file name, yes, I'd

>>>>>>>>> expect a contiguous file to be created. However, Save is a much

>>>>>>>>> faster operation,

>>>>>>>>> Ctrl-S, with no dialog box to fill out.

>>>>>>>>>

>>>>>>>>> Bill

Guest Gerry
Posted

Re: Problem Defragging Large File

 

Colin

 

You have ignored what I said and gone off on a tangent. Please respond

to the point I made.

 

 

 

~~~~

 

 

Gerry

~~~~

FCA

Stourport, England

Enquire, plan and execute

~~~~~~~~~~~~~~~~~~~

 

Colin Barnhorst wrote:

> Save As will always create a complete new file in a new location.

>

> As far as I know the operation is designed to be quick and be gone,

> whether Save or Save As. I don't think the file manager messes

> around with the existing file. There are too many variables and it

> would take too long. In any case it does not insert data into an

> existing file. It either saves the changes and updates the file

> structure data (Save) or it saves a new copy of the file and marks

> the old for deletion if a new file name, path, or type is not

> specified (Save As).

> The Save command is not designed to analyse the file, find an

> insertion point, open, insert, close, etc. It is a quick and dirty

> operation.

> Open uses the links recorded by Save to stitch the file fragments back

> together in the correct sequence when the file is again called into

> memory. This sewing machine effect is most noticeable when the drive

> heads start tracking all over the drive to get all the pieces.

>

> "Gerry" <gerry@nospam.com> wrote in message

> news:eHa1rMRuIHA.1936@TK2MSFTNGP04.phx.gbl...

>> Colin

>>

>> What you say about Save As depends on how large the file is and

>> whether the next available free disk space is of sufficient size to

>> accomodate the file.

>>

>> --

>>

>>

>>

>> Hope this helps.

>>

>> Gerry

>> ~~~~

>> FCA

>> Stourport, England

>> Enquire, plan and execute

>> ~~~~~~~~~~~~~~~~~~~

>>

>> Colin Barnhorst wrote:

>>> Save As saves a contiguous file in a new location. Save saves only

>>> the changes in a new location.

>>>

>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message

>>> news:%23KEFfrKuIHA.748@TK2MSFTNGP05.phx.gbl...

>>>> I don't think that's true (that "Save As" saves in a new location,

>>>> and Save doesn't). In either case, if the file exists, it will be

>>>> overwritten in the same location(s), to the best of my knowledge

>>>> (meaning it will be fragmented, too, since the operating system

>>>> just looks for free clusters). Colin Barnhorst wrote:

>>>>> Save As doesn't save over it. It saves in a new location

>>>>> regardless of whether you give it a new filename or not. The

>>>>> difference is whether or not

>>>>> the old copy stays (if you give a new name) or is marked for

>>>>> deletion. "Bill in Co." <not_really_here@earthlink.net> wrote in

>>>>> message

>>>>> news:eI$K%23bJuIHA.4876@TK2MSFTNGP02.phx.gbl...

>>>>>> Actually, I'm pretty certain I was right the first time. There

>>>>>> is NO difference between using "Save" and "Save As",

>>>>>> EXCEPT for allowing for a different filename.

>>>>>>

>>>>>> If the file is already there and fragmented, and you save over it

>>>>>> (either

>>>>>> way!), it will STAY fragmented.

>>>>>>

>>>>>> If the file isn't there, and you save it, it makes no difference

>>>>>> which way

>>>>>> you save it.

>>>>>>

>>>>>> If I'm wrong, show me the site supporting that.

>>>>>>

>>>>>> And the fact that the operating system marks the first cluster to

>>>>>> indicate

>>>>>> the file is deleted has nothing to do with this *specific*

>>>>>> discussion. Bill in Co. wrote:

>>>>>>> Colin Barnhorst wrote:

>>>>>>>> Save As always saves the whole file. When you confirm usage of

>>>>>>>> the existing

>>>>>>>> file name it still writes a fresh, contiguous copy file and

>>>>>>>> marks the old

>>>>>>>> one for deletion.

>>>>>>>

>>>>>>> Are you sure? And you're also saying that just using SAVE will

>>>>>>> NOT do that? (in both cases using the same file name of a file

>>>>>>> that is already

>>>>>>> on

>>>>>>> the disk)

>>>>>>>

>>>>>>>> When you change the filename it writes the new file with

>>>>>>>> the new name but does not mark the old one for deletion.

>>>>>>>

>>>>>>> But in both cases above, we're NOT changing the filename.

>>>>>>>

>>>>>>>> "Bill Sharpe" <wfsnopam@adelphia.net> wrote in message

>>>>>>>> news:ujE4G0GuIHA.1936@TK2MSFTNGP04.phx.gbl...

>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>> It is how the two commands have always worked and why when

>>>>>>>>>> you use the

>>>>>>>>>> Save As command you are prompted if the file already exists

>>>>>>>>>> as to whether

>>>>>>>>>> or not you want to replace the existing one.

>>>>>>>>>>

>>>>>>>>>> The Save command only saves the changes to the file and saves

>>>>>>>>>> them in

>>>>>>>>>> the next available place large enough for the fragment. That

>>>>>>>>>> can be anywhere

>>>>>>>>>> on the drive. The file manager then records a link and the

>>>>>>>>>> next time

>>>>>>>>>> the

>>>>>>>>>> file is read into memory the file system follows the links

>>>>>>>>>> until all of

>>>>>>>>>> the file is in memory. That's what causes the heads to

>>>>>>>>>> sometimes skip

>>>>>>>>>> all over the place when loading the file and why it takes a

>>>>>>>>>> long time

>>>>>>>>>> and a lot of disk activity to load some files.

>>>>>>>>>>

>>>>>>>>>> If the file is a series of fragments scattered all over the

>>>>>>>>>> drive then

>>>>>>>>>> selecting Save As will write a new, contiguous copy in a

>>>>>>>>>> location that

>>>>>>>>>> can hold it, thus eliminating the need for links. The file

>>>>>>>>>> manager then

>>>>>>>>>> marks the old pieces as available and the next defrag will

>>>>>>>>>> consolidate

>>>>>>>>>> these pieces of free space into larger contiguous areas

>>>>>>>>>> available for

>>>>>>>>>> writes. In the meantime disk performance improves because

>>>>>>>>>> the drive heads are moving far less, shortening access time

>>>>>>>>>> and reducing wear and

>>>>>>>>>> tear. There is no downside that I know of to using Save As

>>>>>>>>>> except the

>>>>>>>>>> additional step of confirming the "overwrite". No overwrite

>>>>>>>>>> takes place,

>>>>>>>>>> of course, since it is a new write. "Overwrite" is just an

>>>>>>>>>> anecdotal

>>>>>>>>>> descriptor for what really happens.

>>>>>>>>>>

>>>>>>>>>> This is a very old computer tip that is still valid. If you

>>>>>>>>>> search the

>>>>>>>>>> web though you will see explanations of the difference

>>>>>>>>>> between the two

>>>>>>>>>> commands as simply being that Save As offers the opportunity

>>>>>>>>>> to create

>>>>>>>>>> a

>>>>>>>>>> new copy while keeping the old one by changing the file

>>>>>>>>>> name. That is

>>>>>>>>>> one of the reasons to sometimes use Save As but by no means

>>>>>>>>>> the most useful IMHO.

>>>>>>>>>>

>>>>>>>>>> It is understanding what the Save command does NOT do that is

>>>>>>>>>> the key.

>>>>>>>>>> It does not save the entire file, but only the changes from

>>>>>>>>>> the current

>>>>>>>>>> session. These are not written into the existing file but in

>>>>>>>>>> a new location large enough to hold the changes.

>>>>>>>>>>

>>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in

>>>>>>>>>> message news:e$6wHBGuIHA.3780@TK2MSFTNGP03.phx.gbl...

>>>>>>>>>>> But see, if he removes and deletes the file, and then runs

>>>>>>>>>>> defrag, there

>>>>>>>>>>> won't be much there to defrag so it will be fast, and then

>>>>>>>>>>> when he copies it back *to a freshly defragmented drive*, it

>>>>>>>>>>> should be stored

>>>>>>>>>>> there in contiguous sectors, right?

>>>>>>>>>>>

>>>>>>>>>>> ALSO:

>>>>>>>>>>> "Save as" always stores a contiguous file? And "save"

>>>>>>>>>>> doesn't? I didn't know that. Do you have some reference

>>>>>>>>>>> article on that? (I'm

>>>>>>>>>>> assuming we're not talking about just overwriting an

>>>>>>>>>>> existing file when

>>>>>>>>>>> using Save, which may be different)

>>>>>>>>>>>

>>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>>> It doesn't matter how he does it because a heavily fragged

>>>>>>>>>>>> drive will

>>>>>>>>>>>> suffer far more wear and tear from head movement than any

>>>>>>>>>>>> defragging

>>>>>>>>>>>> operation will

>>>>>>>>>>>> ever cause. The easiest tip for reducing fragmentation in

>>>>>>>>>>>> the first

>>>>>>>>>>>> place

>>>>>>>>>>>> is to avoid using the Save command and stick to Save As.

>>>>>>>>>>>> That way the

>>>>>>>>>>>> new or edited file is always contiguous.

>>>>>>>>>>>>

>>>>>>>>>>>> "Bill in Co." <not_really_here@earthlink.net> wrote in

>>>>>>>>>>>> message news:ej2LRuFuIHA.2064@TK2MSFTNGP05.phx.gbl...

>>>>>>>>>>>>> Probably be less and wear and tear (and faster!!) to do it

>>>>>>>>>>>>> the way

>>>>>>>>>>>>> Gerry mentioned, however.

>>>>>>>>>>>>>

>>>>>>>>>>>>> Colin Barnhorst wrote:

>>>>>>>>>>>>>> Try downloading a trial copy of PerfectDisk or Diskeeper

>>>>>>>>>>>>>> and letting

>>>>>>>>>>>>>> it defrag the file. You can uninstall the software

>>>>>>>>>>>>>> afterwards. Either

>>>>>>>>>>>>>> of those defraggers are excellent at this particular type

>>>>>>>>>>>>>> of defragging.

>>>>>>>>>>>>>>

>>>>>>>>>>>>>> "ColTom2" <noemailaddress@nomail.com> wrote in message

>>>>>>>>>>>>>> news:ecfYKB8tIHA.4376@TK2MSFTNGP06.phx.gbl...

>>>>>>>>>>>>>>> Hi:

>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> I had a file that was over 13BG in size and the Windows

>>>>>>>>>>>>>>> defrag process

>>>>>>>>>>>>>>> went fine defragging the file per se. However, when the

>>>>>>>>>>>>>>> defrag process tried

>>>>>>>>>>>>>>> to move this large file it always hung up at 3%. As long

>>>>>>>>>>>>>>> as the file itself

>>>>>>>>>>>>>>> was being defragged everything was OK, but when it came

>>>>>>>>>>>>>>> to trying

>>>>>>>>>>>>>>> to move this file is where it always hung up.

>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> Does anyone have a solution to defragging a large file

>>>>>>>>>>>>>>> of this size

>>>>>>>>>>>>>>> within Windows XP?

>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>> Thanks

>>>>>>>>>>>

>>>>>>>>>>>

>>>>>>>>>>

>>>>>>>>> If you don't change the file name, I would think "save as"

>>>>>>>>> would work the

>>>>>>>>> same way as "save." If you do change the file name, yes, I'd

>>>>>>>>> expect a contiguous file to be created. However, Save is a

>>>>>>>>> much faster operation,

>>>>>>>>> Ctrl-S, with no dialog box to fill out.

>>>>>>>>>

>>>>>>>>> Bill

×
×
  • Create New...