clipka wrote:
> Darren New schrieb:
>>> Then again, I've sometimes wondered what would happen if you had some 
>>> filesystem that split the disk into several seperate regions with 
>>> different block sizes, and allocated files accordingly. (I.e., put 
>>> the really huge files in the area with big blocks, and the tiny files 
>>> in some area with tiny block sizes.) I rather suspect you'd 
>>> permanently be running out of whichever size you happen to need the 
>>> most tho...
>>
>> And interesting thought. I've never seen that done.  Given that disks 
>> are broken into sectors all the same size, and given that the only 
>> reasons for allocating space in units larger than one sector are 
>> defragmentation and efficiency of storing pointers to clusters, 
>> there's no real good reason for it.
> 
> You are aware that modern file systems use block sizes /significantly/ 
> larger than the disk sector size?

Thats what I said.

> A disk sector is 512 byte in size virtually everywhere, while file 
> systems typically use block sizes one order of magnitude larger.
> 
> Why? Because it is actually more memory-efficient to /not/ use even the 
> smallest gaps - because that inflates the required management overhead, 
> severely reducing the total payload capacity when the files are 
> sufficiently /large/ on average.

I take it you didn't actually read what I wrote?

"The only reasons for allocating space larger than one sector are 
defragmentation and efficiency of storing pointers to clusters."

Incidentally, the management overhead isn't that high when the structure you 
use to store the location of files isn't O(n) in the number of clusters. 
NTFS, for example, stores file extents: an unfragmented file will occupy the 
same amount of space to describe its location regardless of file size.

> In the end, some compromise is used, based on the statistical 
> distribution of file sizes. A really /good/ system administrator might 
> tune the various volumes on his systems to have block sizes that match 
> the actual use.

Yep. Or you just buy a bigger drive. :-)

>> On the other hand, the Amiga formatted the floppy track every time it 
>> wrote the track, so you could probably actually fit more large files 
>> on a disk than small files, even if every small file was exactly one 
>> sector, by making the sectors physically larger on tracks where they 
>> store a big file.
> 
> That won't work for hard disk drives:

Hence my specification that it was only Amiga floppy drives, yes. Indeed, 
even other controllers wouldn't do it efficiently, requiring two rotations 
of the disk to first format then write it. The Amiga used the DSP hardware 
(if you want to call it that) to do the MFM encoding, so it could 
efficiently encode the track every time it wrote it without hardware 
dedicated just to that.


> provided he has kept 
> an eye on the SMART status of his drives).

Google says this doesn't work nearly as well as you might like it to. :-)


-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New schrieb:
> I take it you didn't actually read what I wrote?

Well, I did, but I may have perfectly misunderstood what you had written.

Post a reply to this message

clipka wrote:
> Darren New schrieb:
>> I take it you didn't actually read what I wrote?
> 
> Well, I did, but I may have perfectly misunderstood what you had written.

Fair enough. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Thank you all for your input, friends, though this comes a bit late. Work 
got in the way yesterday, so I could not access the newsgroup. I gained some 
valuable insights into ext2.



Since some of you asked what I did not like about ADS on NTFS, here it is:



There is no easy way to access ADS in Windows Explorer. The only way to do 
it is use API-calls to access the ADS (to my best knowledge).



Again to my best knowledge (which is somewhat lacking in the field of file 
systems, admittedly), you have to scan every single directory using 
API-calls to determine which ADS-files are stored on your HDD.



And most importantly, if you store data in ADS, it is nowhere reported in 
Windows Explorer. I have heard it said that you could run into serious 
problems if you HDD seems to be almost full - but in truth >is< completely 
full, because of ADS-files which file-sizes are reported nowhere.



So, if you are in the mood, you could fill a seemingly empty HDD by creating 
a few really huge ADS-files on  it.



Anybody wanting to write to this HDD should be ready for an interesting 
experience...



I hope linux ext2 does not do the same.

Post a reply to this message

TC wrote:

> Since some of you asked what I did not like about ADS on NTFS, here it is:
> 
> 
> 
> There is no easy way to access ADS in Windows Explorer. The only way to do 
> it is use API-calls to access the ADS (to my best knowledge).

In fact, you don't need any special API calls. There is a filename 
syntax for accessing alternate streams. For example:

C:\> echo This is a test > Test.txt
C:\> echo This is another test > Test.txt:alt

Congratulations, you just greated a file with an ADS named "alt".

I will admit, however, that most programs don't know about this 
"feature" and will complain if you try to use it. (E.g. both the TYPE 
command and Notepad complain that no such file exists.)

> And most importantly, if you store data in ADS, it is nowhere reported in 
> Windows Explorer.

This appears to be true. Even the "size on disk" field doesn't appear to 
change when adding and removing ADS, with is rather anomolous.

Still, most ADS are so tiny it probably doesn't matter too much.

Post a reply to this message

TC schrieb:

> Since some of you asked what I did not like about ADS on NTFS, here it is:

So what you're basically saying is you don't hate ADS - you hate Windows 
Explorer's poor (or actually nonexistent) support for it.

Post a reply to this message

TC wrote:
> There is no easy way to access ADS in Windows Explorer. The only way to do 
> it is use API-calls to access the ADS (to my best knowledge).

You can open any stream by name. It's


C:\Users\Darren\Desktop>echo hello >hello.txt
C:\Users\Darren\Desktop>echo goodbye >hello.txt:goodbye.txt
C:\Users\Darren\Desktop>type hello.txt
hello
C:\Users\Darren\Desktop>more < hello.txt:goodbye.txt
goodbye

Some programs try to parse the file name, but < and > don't, so it works fine.

Of course, yes, to get a list of what streams are out there, you need API calls.

> Again to my best knowledge (which is somewhat lacking in the field of file 
> systems, admittedly), you have to scan every single directory using 
> API-calls to determine which ADS-files are stored on your HDD.

Yes. As is true of Linux's extended attributes and Mac's file forks, too.

> So, if you are in the mood, you could fill a seemingly empty HDD by creating 
> a few really huge ADS-files on  it.

Yep.

> Anybody wanting to write to this HDD should be ready for an interesting 
> experience...

If you're malicious and don't care if you get caught after the fact, and the 
person you're pulling this trick on doesn't know about ADS, then yes, this 
can happen.

Now that you know, go download the free program that scans your disk and 
finds your ADS's for you, and you don't have to worry any more. :-)

> I hope linux ext2 does not do the same.

I believe ext2 puts an upper limit on how much you can store in ADS. 
Something like 64K IIRC.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Yes, I realize you are completely right ;-)

It is not the fault of ADS that Windows makes it hard for us to know what is 
actually stored on the hdd.

I always wonder when the first virus/worms make use of this "feature"... do 
you know if anti-vir scanners look for ADS-files with malicious payload?

"clipka" <ano### [at] anonymousorg> schrieb im Newsbeitrag 
news:4ab37e5e$1@news.povray.org...
> TC schrieb:
>
>> Since some of you asked what I did not like about ADS on NTFS, here it 
>> is:
>
> So what you're basically saying is you don't hate ADS - you hate Windows 
> Explorer's poor (or actually nonexistent) support for it.

Post a reply to this message

Hi, Darren,

thank you, but I know of this and already have programs which can identify 
ADS. Nonetheless, it is no fun scanning a couple of 1.5 TB for possibly 
malicious files.

As clipka did make me realize: i really don't care for ADS one way or the 
other - it might even be useful - but I hate Windows Explorers complete lack 
of support for it.

"Darren New" <dne### [at] sanrrcom> schrieb im Newsbeitrag 
news:4ab3b070$1@news.povray.org...
> TC wrote:
>> There is no easy way to access ADS in Windows Explorer. The only way to 
>> do it is use API-calls to access the ADS (to my best knowledge).
>
> You can open any stream by name. It's
>
>
> C:\Users\Darren\Desktop>echo hello >hello.txt
> C:\Users\Darren\Desktop>echo goodbye >hello.txt:goodbye.txt
> C:\Users\Darren\Desktop>type hello.txt
> hello
> C:\Users\Darren\Desktop>more < hello.txt:goodbye.txt
> goodbye
>
> Some programs try to parse the file name, but < and > don't, so it works 
> fine.
>
> Of course, yes, to get a list of what streams are out there, you need API 
> calls.
>
>> Again to my best knowledge (which is somewhat lacking in the field of 
>> file systems, admittedly), you have to scan every single directory using 
>> API-calls to determine which ADS-files are stored on your HDD.
>
> Yes. As is true of Linux's extended attributes and Mac's file forks, too.
>
>> So, if you are in the mood, you could fill a seemingly empty HDD by 
>> creating a few really huge ADS-files on  it.
>
> Yep.
>
>> Anybody wanting to write to this HDD should be ready for an interesting 
>> experience...
>
> If you're malicious and don't care if you get caught after the fact, and 
> the person you're pulling this trick on doesn't know about ADS, then yes, 
> this can happen.
>
> Now that you know, go download the free program that scans your disk and 
> finds your ADS's for you, and you don't have to worry any more. :-)
>
>> I hope linux ext2 does not do the same.
>
> I believe ext2 puts an upper limit on how much you can store in ADS. 
> Something like 64K IIRC.
>
> -- 
>   Darren New, San Diego CA, USA (PST)
>   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

On Fri, 18 Sep 2009 20:54:16 +0200, TC get-enough-spam-already-2498.com>  
<do-not-reply@i-do> wrote:
> I always wonder when the first virus/worms make use of this "feature"...

They already exist.


> do you know if anti-vir scanners look for ADS-files with malicious  
> payload?

At least some of them do.



-- 
FE

Post a reply to this message