Fa3ien escribió:
> Nicolas Alvarez a écrit :
>> Fa3ien escribió:
>>> I've run a defrag, which freed 250 Mb.
>>
>> Defrags free disk space??
> 
> Theorically, it shouldn't, I'm surprised too.  The fact
> is that Windows seen more free space after defrag.
> chkdsk freed the rest !
> 

Ah that's why. Defrag does *some* disk checking before starting. I doubt 
it does a full chkdsk, or it would have (seemed to) solve your problem.

Post a reply to this message

Nicolas Alvarez nous apporta ses lumieres en ce 2007/11/09 09:46:
> Fa3ien escribió:
>> I've run a defrag, which freed 250 Mb.
> 
> Defrags free disk space??
The OS want to assign a minimum contiguous space to any new or altered file. Any 
free space lower than that thresshold is wasted, and often not reported. 
Defragmenting consolidate that wasted space at the same tima it put fragmented 
files back together.

-- 
Alain
-------------------------------------------------
Experience hath shewn, that even under the best forms of government those
entrusted with power have, in time, and by slow operations, perverted it
into tyranny.
Thomas Jefferson

Post a reply to this message

Fa3ien nous apporta ses lumieres en ce 2007/11/09 15:11:
> Orchid XP v7 a écrit :
>> Fa3ien wrote:
>>
>>> In short, a good'ol chkdsk /f solved the problem.
>>> I didn't knew that so much empty space could be
>>> erroneously marked as allocated...
>>
>> Woah! o_O
>>
>> That's one unhappy filesystem... heh. Glad it's all fixed now though. 
>> (Although you probably ought to find out *why* it did this in the 
>> first place...)
> 
> I'll check regularly to see if it happens again... Maybe it's related
> to the problems I had with Raid in may. I currently run the server
> without Raid1, because the bad experience showed me that no raid (with
> a daily backup, anyway) is less of a potential hassle than shitty SIS
> software Raid (which is more insecure because it doesn't inform you
> correctly of the real array state).
> 
> Fabien.
Faulty raid! Ugly. UGLY! *UGLY!!!!!*
Ready to bet that is was the reason of your vanishing space.

-- 
Alain
-------------------------------------------------
An organizer for the "Million Agoraphobics March" expressed disappointment in 
the turnout for last weekend's event.

Post a reply to this message

M_a_r_c wrote:
> "Nicolas Alvarez" <nic### [at] gmailisthebestcom> a écrit dans le 
> message de news: 473472c5$1@news.povray.org...
>> Fa3ien escribió:
>>> I've run a defrag, which freed 250 Mb.
>> Defrags free disk space??
> 
> I am not an expert but maybe if it optimizes disk occupation by filling 
> blocks instead of letting empty portions of blocks.

More precisely, if you have a fragmented file taking 3 blocks and 
filling them each only 10%, defragging that file will free two blocks.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Fa3ien wrote:
> WHERE IS THE REST ? (there should be 60 Gb free !)

Besides chkdsk, I was going to suggest making sure nobody has an open, 
deleted file that's real big, like some logfile output that someone 
deleted the file name but didn't close the program yet that has it open.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

On Sun, 11 Nov 2007 15:26:48 -0800, Darren New wrote:

> More precisely, if you have a fragmented file taking 3 blocks and
> filling them each only 10%, defragging that file will free two blocks.

I don't think that can happen with "standard" files in NTFS or FAT - why 
would the OS write to a partial block but not the entire block?  Doesn't 
make sense to me...

Jim

Post a reply to this message

Darren New wrote:
> M_a_r_c wrote:
>> "Nicolas Alvarez" <nic### [at] gmailisthebestcom> a écrit dans 
>> le message de news: 473472c5$1@news.povray.org...
>>> Fa3ien escribió:
>>>> I've run a defrag, which freed 250 Mb.
>>> Defrags free disk space??
>>
>> I am not an expert but maybe if it optimizes disk occupation by 
>> filling blocks instead of letting empty portions of blocks.
> 
> More precisely, if you have a fragmented file taking 3 blocks and 
> filling them each only 10%, defragging that file will free two blocks.

More precisely, how would this situation arrise in the first place?

The allocation engine allocates a full block to a file, and does not 
allocate any additional ones until the present ones are full.

As noted elsewhere, in this case it's likely that the defrag partially 
corrected the freelists or something. (Remember, the filesystem was 
corrupted.)

Post a reply to this message

Jim Henderson nous apporta ses lumieres en ce 2007/11/12 13:43:
> On Sun, 11 Nov 2007 15:26:48 -0800, Darren New wrote:
> 
>> More precisely, if you have a fragmented file taking 3 blocks and
>> filling them each only 10%, defragging that file will free two blocks.
> 
> I don't think that can happen with "standard" files in NTFS or FAT - why 
> would the OS write to a partial block but not the entire block?  Doesn't 
> make sense to me...
> 
> Jim
Ever heard of "sparse" files?

-- 
Alain
-------------------------------------------------
To define recursion, we must first define recursion.

Post a reply to this message

On Mon, 12 Nov 2007 19:20:08 -0500, Alain wrote:

> Ever heard of "sparse" files?

Yes.  Old hand at NetWare; didn't know that Windows filesystems supported 
sparse files.

Jim

Post a reply to this message

Jim Henderson wrote:
> On Sun, 11 Nov 2007 15:26:48 -0800, Darren New wrote:
> 
>> More precisely, if you have a fragmented file taking 3 blocks and
>> filling them each only 10%, defragging that file will free two blocks.
> 
> I don't think that can happen with "standard" files in NTFS or FAT 

I don't know about FAT, but I was surprised when I saw a log file that 
actually consumed more clusters than there were lines in the file. WTF?

> would the OS write to a partial block but not the entire block?  Doesn't 
> make sense to me...

Open the file, write a little bit, close it. Open it again, append a 
little, close it. Repeat.  Possibly it requires other people to also 
have the file open at the same time, as for reading or something?

NTFS isn't very good at avoiding fragmentation, methinks.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Jim Henderson wrote:
> On Mon, 12 Nov 2007 19:20:08 -0500, Alain wrote:
> 
>> Ever heard of "sparse" files?
> 
> Yes.  Old hand at NetWare; didn't know that Windows filesystems supported 
> sparse files.

Yah, it does. Well, NTFS does, at least. Indeed, fundamental parts of 
the system (like the USN journal) rely on the fact that you can delete 
blocks off the start of a file and recover the space used therein.

Unlike UNIX, it's not just a matter of seeking around. You have to open 
the file as a sparse file, then you have to say "hey, this area is 
sparse" rather than (say) just writing all zeros to the blocks or something.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Orchid XP v7 wrote:
> The allocation engine allocates a full block to a file, and does not 
> allocate any additional ones until the present ones are full.

How do you know?

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

On Mon, 12 Nov 2007 20:39:45 -0800, Darren New wrote:

> Jim Henderson wrote:
>> On Mon, 12 Nov 2007 19:20:08 -0500, Alain wrote:
>> 
>>> Ever heard of "sparse" files?
>> 
>> Yes.  Old hand at NetWare; didn't know that Windows filesystems
>> supported sparse files.
> 
> Yah, it does. Well, NTFS does, at least. Indeed, fundamental parts of
> the system (like the USN journal) rely on the fact that you can delete
> blocks off the start of a file and recover the space used therein.
> 
> Unlike UNIX, it's not just a matter of seeking around. You have to open
> the file as a sparse file, then you have to say "hey, this area is
> sparse" rather than (say) just writing all zeros to the blocks or
> something.

Ah, I see - learned something new today. :-)

Jim

Post a reply to this message

On Mon, 12 Nov 2007 20:38:07 -0800, Darren New wrote:

> Open the file, write a little bit, close it. Open it again, append a
> little, close it. Repeat.  Possibly it requires other people to also
> have the file open at the same time, as for reading or something?

Don't think so.  Sparse files I could see, but a proper sparse file 
wouldn't shrink during a defrag, either, based on my own experiences, 
because the "empty" space is as important as the real data is to the 
application.

Jim

Post a reply to this message

Jim Henderson wrote:
> On Mon, 12 Nov 2007 20:38:07 -0800, Darren New wrote:
> 
>> Open the file, write a little bit, close it. Open it again, append a
>> little, close it. Repeat.  Possibly it requires other people to also
>> have the file open at the same time, as for reading or something?
> 
> Don't think so.

I don't know. All I can say is that I've seen files with 2K length 
spread over half a dozen blocks as reported by defrag. :-)  I'm not sure 
what causes it.

Try running the defrag GUI version, look at the report, and see if 
things like your registry hives or event logs are fragmented and how 
much. In my expereince, it's not uncommon.

>  Sparse files I could see, but a proper sparse file 
> wouldn't shrink during a defrag, either, based on my own experiences, 
> because the "empty" space is as important as the real data is to the 
> application.

Yah. Sparse files are already deallocated, so you can't really 
deallocate more.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New wrote:
> I don't know. All I can say is that I've seen files with 2K length 
> spread over half a dozen blocks as reported by defrag. :-)  I'm not sure 
> what causes it.

I mean, 43 fragments for a 1K ntuser.dat?  15 fragments for a 1K 
default.log? In a 4K cluster size?  Clearly, there has to be fragmented 
files with not-fully-packed blocks, if defrag is to be believed.

Maybe that's the problem tho - the layout is right, the reporting is funky.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Attachments:
Download 'image1.gif' (14 KB)

Preview of image 'image1.gif'

Darren New escribió:
> Unlike UNIX, it's not just a matter of seeking around. You have to open 
> the file as a sparse file, then you have to say "hey, this area is 
> sparse" rather than (say) just writing all zeros to the blocks or 
> something.

Not really... Cross-platform programs that don't use any 
Windows-specific API manage to create sparse files here. That's why 
download managers that download in chunks give the option to 
pre-allocate: sparse files that are filled randomly get fragmented quite 
badly.

Post a reply to this message

Darren New escribió:
> I mean, 43 fragments for a 1K ntuser.dat?

That's probably mis-reporting the size. NTUSER.DAT has the whole user 
registry hive. It's 6MB on my machine, no way it can be 1K on yours.

Post a reply to this message

On Tue, 13 Nov 2007 08:32:14 -0800, Darren New wrote:

> Jim Henderson wrote:
>> On Mon, 12 Nov 2007 20:38:07 -0800, Darren New wrote:
>> 
>>> Open the file, write a little bit, close it. Open it again, append a
>>> little, close it. Repeat.  Possibly it requires other people to also
>>> have the file open at the same time, as for reading or something?
>> 
>> Don't think so.
> 
> I don't know. All I can say is that I've seen files with 2K length
> spread over half a dozen blocks as reported by defrag. :-)  I'm not sure
> what causes it.

At a guess, corruption. :-)
> Try running the defrag GUI version, look at the report, and see if
> things like your registry hives or event logs are fragmented and how
> much. In my expereince, it's not uncommon.

Hmmm, well, the only Windows I have installed is in VMware with virtual 
disks, so I'm unlikely to run across this, I think.

>>  Sparse files I could see, but a proper sparse file
>> wouldn't shrink during a defrag, either, based on my own experiences,
>> because the "empty" space is as important as the real data is to the
>> application.
> 
> Yah. Sparse files are already deallocated, so you can't really
> deallocate more.

Yep.

Jim

Post a reply to this message

On Tue, 13 Nov 2007 08:37:37 -0800, Darren New wrote:

> I mean, 43 fragments for a 1K ntuser.dat?  15 fragments for a 1K
> default.log? In a 4K cluster size?  Clearly, there has to be fragmented
> files with not-fully-packed blocks, if defrag is to be believed.

Weird.  Though based on my experiences with Active Directory, I'm not 
inclined to believe what any Microsoft utility tells me.  I've seen two 
different hardware diagnostics point fingers at each other, but with 
Windows 2000 Server, I had a first - two programs that were intended to 
tell me the health of my domain that couldn't agree with each other.  
Both from the same vendor.

> Maybe that's the problem tho - the layout is right, the reporting is
> funky.

Could be.

Jim

Post a reply to this message

Darren New wrote:
> Orchid XP v7 wrote:
>> The allocation engine allocates a full block to a file, and does not 
>> allocate any additional ones until the present ones are full.
> 
> How do you know?

Well, put it this way: This is a trivial algorithm, and there is 
absolutely no *reason* why it would do anything different, so...

Post a reply to this message

Jim Henderson nous apporta ses lumieres en ce 2007/11/12 19:37:
> On Mon, 12 Nov 2007 19:20:08 -0500, Alain wrote:
> 
>> Ever heard of "sparse" files?
> 
> Yes.  Old hand at NetWare; didn't know that Windows filesystems supported 
> sparse files.
> 
> Jim
Was even supported under DOS 3, maybe earlier.

-- 
Alain
-------------------------------------------------
Always try to be modest, and be proud of it!

Post a reply to this message

Nicolas Alvarez nous apporta ses lumieres en ce 2007/11/13 12:41:
> Darren New escribió:
>> Unlike UNIX, it's not just a matter of seeking around. You have to 
>> open the file as a sparse file, then you have to say "hey, this area 
>> is sparse" rather than (say) just writing all zeros to the blocks or 
>> something.
> 
> Not really... Cross-platform programs that don't use any 
> Windows-specific API manage to create sparse files here. That's why 
> download managers that download in chunks give the option to 
> pre-allocate: sparse files that are filled randomly get fragmented quite 
> badly.
And can have TONS of slack space! Just imagine a file whose records are about 64 
bytes each, and only having less than 0.01% of them actualy used... with 
clusters of 4Kb. You are stuck with many clusters containing only 1 record, at 
some random location in the cluster.

-- 
Alain
-------------------------------------------------
Moonies: Only really happy shit happens.

Post a reply to this message

Orchid XP v7 nous apporta ses lumieres en ce 2007/11/12 13:58:
> Darren New wrote:
>> M_a_r_c wrote:
>>> "Nicolas Alvarez" <nic### [at] gmailisthebestcom> a écrit 
>>> dans le message de news: 473472c5$1@news.povray.org...
>>>> Fa3ien escribió:
>>>>> I've run a defrag, which freed 250 Mb.
>>>> Defrags free disk space??
>>>
>>> I am not an expert but maybe if it optimizes disk occupation by 
>>> filling blocks instead of letting empty portions of blocks.
>>
>> More precisely, if you have a fragmented file taking 3 blocks and 
>> filling them each only 10%, defragging that file will free two blocks.
> 
> More precisely, how would this situation arrise in the first place?
> 
> The allocation engine allocates a full block to a file, and does not 
> allocate any additional ones until the present ones are full.
> 
How can you assume that it only allocate a single block? NTFS allocate some 
cluster when you create a new file in an attempt to reduce fragmentation that 
appens when several files are created at once and randomly filled. Once the file 
is closed, the unused clusters are liberated. It does the same when all the 
file's alocated space is filled ant it need some more disk space. That 
prealocated space must reside in successive clusters.

-- 
Alain
-------------------------------------------------
Fix reason firmly in her seat, and call to her tribunal every fact, every
opinion. Question with boldness even the existence of a God; because, if
there be one, he must more approve of the homage of reason, than that of
blindfolded fear.
Thomas Jefferson

Post a reply to this message

Alain escribió:
> Nicolas Alvarez nous apporta ses lumieres en ce 2007/11/13 12:41:
>>
>> Not really... Cross-platform programs that don't use any 
>> Windows-specific API manage to create sparse files here. That's why 
>> download managers that download in chunks give the option to 
>> pre-allocate: sparse files that are filled randomly get fragmented 
>> quite badly.
> And can have TONS of slack space! Just imagine a file whose records are 
> about 64 bytes each, and only having less than 0.01% of them actualy 
> used... with clusters of 4Kb. You are stuck with many clusters 
> containing only 1 record, at some random location in the cluster.
> 

Of course. The file usage on disk grows while it gets downloaded. But in 
the end, it will eventually be totally downloaded and extremely 
fragmented. So in those cases it's a good idea to pre-allocate. If you 
will have lots of "unused records" for long periods, then yes it's a 
good idea to let it use sparse files.

Post a reply to this message

Nicolas Alvarez wrote:
> Darren New escribió:
>> Unlike UNIX, it's not just a matter of seeking around. You have to 
>> open the file as a sparse file, then you have to say "hey, this area 
>> is sparse" rather than (say) just writing all zeros to the blocks or 
>> something.
> 
> Not really... Cross-platform programs that don't use any 
> Windows-specific API manage to create sparse files here.

I think if you write to it, regardless of what you write, you get 
allocated space. UNIX *used* to see an all-zeros buffer and say "Gee, we 
don't need to write that."  You didn't have to seek over the sparse 
space to make it sparse, IIRC.

I think the calls I'm thinking of are for making an existing data area 
sparse, too; i.e., throwing away the beginning of a log file without 
changing offsets of existing records. And you may even need to open the 
file in "sparse" mode.

Or, I could be completely wrong. This one I never actually did. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Alain wrote:
> Jim Henderson nous apporta ses lumieres en ce 2007/11/12 19:37:
>> On Mon, 12 Nov 2007 19:20:08 -0500, Alain wrote:
>>
>>> Ever heard of "sparse" files?
>>
>> Yes.  Old hand at NetWare; didn't know that Windows filesystems 
>> supported sparse files.
>>
>> Jim
> Was even supported under DOS 3, maybe earlier.

What, on FAT?  Nah.  Would have to be some other format, cause FAT 
doesn't have the data structures for that.

CP/M did, actually, now that I think of it. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Nicolas Alvarez wrote:
> Darren New escribió:
>> I mean, 43 fragments for a 1K ntuser.dat?
> 
> That's probably mis-reporting the size. NTUSER.DAT has the whole user 
> registry hive. It's 6MB on my machine, no way it can be 1K on yours.

Yah, OK. Looking at it with DIR is 15 meg or so here.  I *thought* that 
was kind of funky.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Orchid XP v7 wrote:
> Darren New wrote:
>> Orchid XP v7 wrote:
>>> The allocation engine allocates a full block to a file, and does not 
>>> allocate any additional ones until the present ones are full.
>>
>> How do you know?
> 
> Well, put it this way: This is a trivial algorithm, and there is 
> absolutely no *reason* why it would do anything different, so...

I thought Microsoft was generally considered a good reason to do 
anything trivial wrong. ;-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New escribió:
> Nicolas Alvarez wrote:
>> Darren New escribió:
>>> Unlike UNIX, it's not just a matter of seeking around. You have to 
>>> open the file as a sparse file, then you have to say "hey, this area 
>>> is sparse" rather than (say) just writing all zeros to the blocks or 
>>> something.
>>
>> Not really... Cross-platform programs that don't use any 
>> Windows-specific API manage to create sparse files here.
> 
> I think if you write to it, regardless of what you write, you get 
> allocated space. UNIX *used* to see an all-zeros buffer and say "Gee, we 
> don't need to write that."  You didn't have to seek over the sparse 
> space to make it sparse, IIRC.

Right, as far as I know, if you write 0s without using any special 
Windows API, the 0s actually get written (that's the pre-allocation 
download programs do).

Post a reply to this message

Nicolas Alvarez wrote:
> Right, as far as I know, if you write 0s without using any special 
> Windows API, the 0s actually get written (that's the pre-allocation 
> download programs do).

Actually, looking it up on MSDN, it seems more complicated than I 
thought. :-)  But not something I feel like persuing.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

On Tue, 13 Nov 2007 19:21:10 -0500, Alain wrote:

> Jim Henderson nous apporta ses lumieres en ce 2007/11/12 19:37:
>> On Mon, 12 Nov 2007 19:20:08 -0500, Alain wrote:
>> 
>>> Ever heard of "sparse" files?
>> 
>> Yes.  Old hand at NetWare; didn't know that Windows filesystems
>> supported sparse files.
>> 
>> Jim
> Was even supported under DOS 3, maybe earlier.

Um, not according to wikipedia:

http://en.wikipedia.org/wiki/Comparison_of_file_systems

Sparse files are supported on NTFS but not any variation of FAT.  Then 
again, that table doesn't show NWFS or NSS as supporting sparse files 
(which they both do), but lists them as "unknown".

Jim

Post a reply to this message

Jim Henderson escribió:
> Sparse files are supported on NTFS but not any variation of FAT.  Then 
> again, that table doesn't show NWFS or NSS as supporting sparse files 
> (which they both do), but lists them as "unknown".

"Then edit"? :)

Post a reply to this message

On Wed, 14 Nov 2007 03:32:09 +0100, Darren New <dne### [at] sanrrcom> wrote:
> Nicolas Alvarez wrote:
>> Darren New escribió:
>>> I mean, 43 fragments for a 1K ntuser.dat?
>>  That's probably mis-reporting the size. NTUSER.DAT has the whole user  
>> registry hive. It's 6MB on my machine, no way it can be 1K on yours.
>
> Yah, OK. Looking at it with DIR is 15 meg or so here.  I *thought* that  
> was kind of funky.


Note that there is an ellipsis there. Most likely the full name was  
"ntuser.dat.LOG".



-- 
FE

Post a reply to this message

Fredrik Eriksson escribió:
> On Wed, 14 Nov 2007 03:32:09 +0100, Darren New <dne### [at] sanrrcom> wrote:
>> Nicolas Alvarez wrote:
>>> Darren New escribió:
>>>> I mean, 43 fragments for a 1K ntuser.dat?
>>>  That's probably mis-reporting the size. NTUSER.DAT has the whole 
>>> user registry hive. It's 6MB on my machine, no way it can be 1K on 
>>> yours.
>>
>> Yah, OK. Looking at it with DIR is 15 meg or so here.  I *thought* 
>> that was kind of funky.
 >
> Note that there is an ellipsis there. Most likely the full name was 
> "ntuser.dat.LOG".
> 

The .LOG is a constant 32KB. Still doesn't match the 1KB he saw.

Post a reply to this message

On Wed, 14 Nov 2007 19:04:07 +0100, Nicolas Alvarez  
<nic### [at] gmailisthebestcom> wrote:
> Fredrik Eriksson escribió:
>> On Wed, 14 Nov 2007 03:32:09 +0100, Darren New <dne### [at] sanrrcom> wrote:
>>> Nicolas Alvarez wrote:
>>>> Darren New escribió:
>>>>> I mean, 43 fragments for a 1K ntuser.dat?
>>>>  That's probably mis-reporting the size. NTUSER.DAT has the whole  
>>>> user registry hive. It's 6MB on my machine, no way it can be 1K on  
>>>> yours.
>>>
>>> Yah, OK. Looking at it with DIR is 15 meg or so here.  I *thought*  
>>> that was kind of funky.
>  >
>> Note that there is an ellipsis there. Most likely the full name was  
>> "ntuser.dat.LOG".
>>
>
> The .LOG is a constant 32KB. Still doesn't match the 1KB he saw.


At this particular point in time, that file is exactly 1 kB for this user  
account on my machine. The size can vary over time, but 1 kB seems to be a  
minimum.



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> Note that there is an ellipsis there. Most likely the full name was 
> "ntuser.dat.LOG".

Good call. Yes. ntuser.dat.LOG is 1K, 4K on disk, and shows as having 32 
fragments today. Considering 1K of data would (AFAIK) fit in the file 
table itself, it shouldn't even have *one* fragment. I suspect there's 
something funky, like a whole bunch of contiguous "fragments" listed or 
some such.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

On Wed, 14 Nov 2007 01:13:52 -0300, Nicolas Alvarez wrote:

> Jim Henderson escribió:
>> Sparse files are supported on NTFS but not any variation of FAT.  Then
>> again, that table doesn't show NWFS or NSS as supporting sparse files
>> (which they both do), but lists them as "unknown".
> 
> "Then edit"? :)

Again, the time factor.  But at least on that topic I *can* claim some 
expertise.

Jim

Post a reply to this message