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

> Nicolas Alvarez wrote:

>>> 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:

>>> 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

> On Wed, 14 Nov 2007 03:32:09 +0100, Darren New <dne### [at] sanrrcom> wrote:
>> Nicolas Alvarez wrote:

>>>> 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:

>> On Wed, 14 Nov 2007 03:32:09 +0100, Darren New <dne### [at] sanrrcom> wrote:
>>> Nicolas Alvarez wrote:

>>>>> 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