Warp wrote:
>> Part of the problem comes from programs that don't support soft links 
>> getting caught in loops.
> 
>   Soft links are and should be invisible to programs (unless the program
> explicitly wants to distinguish them, as a file explorer would).

Exactly my point. Write a program in Linux that walks a directory tree and 
does *not* account for soft links (or "..") and you have a problem.

>> Why the heck would
> 
>   Did you mispaste that?

I think a meeting popped up.

>   I don't want to see it in a separate dialog. I want to see it in the file
> listing.

http://www.codeproject.com/KB/shell/shellextguideindex.aspx

More specifically,
http://www.codeproject.com/kb/shell/ShellExtGuide8.aspx

>> And which byte count do you want?
> 
>   The size of the file. How many bytes it contains. If I opened it with a
> program and started reading bytes, how many I would get before EOF.

Open it raw, or processed, or for backup?  There's *lots* of file opens in 
Windows. They give you different byte counts.  Do you want the number of 
bytes you'd get by reading the compressed file and uncompressing it on the 
fly, or the number of bytes you'd need to copy the file to another disk, or 
the number of bytes you'd need to store the file in a way that can be 
reconstructed (i.e., with ACLs and such).  And if you have multiple streams, 
do you want the bytes from those streams as well?

Really, files in Windows aren't just "how many bytes."  It's really, 
actually more complicated than that.

>   Windows Explorer already shows that size in the file listing... but not
> in bytes (unless the file happens to be smaller than 1 kB or such). That's
> what's annoying about it.

On the rare occasion I wanted exact byte counts, I used Properties. I find 
it more annoying that Linux doesn't put thousands-separators in numbers, so 
when it shows me the size of a 20G file, it takes me lots of staring to 
figure it out. :-)


>> So write an extension, if it bothers you.
> 
>   You make it sound like it's easy.

Then take the sample above and change it to show the column you want. It 
isn't that hard. Heck, just read thru the text listed on that page and see 
if there's anything that's unclear. (Of course there is, but not obviously 
so. Not so unclear that you'd have a hard time clarifying it. :-)

I'll grant you that I don't know of a trivial scripting solution, but I 
expect putting one of those together would be fun.

>   Seeing the exact size of a file is a pretty common and useful thing to
> want.

For programmers, yes. Not for regular users. And you can see it with one 
extra step. :-)

>   Except that it doesn't tell that. If you try to copy it to another file
> system or an archive file, it will most probably end up taking a completely
> different amount of space.

Hence the "which size do you want" question. :-)  That's another good point: 
if it's an archive, do you want the size of the archive, the size of the 
total files in the archive, etc? :-)

>   Showing how much disk space a file takes is *useless* information. *That*
> is what should be in some info dialog. The file listing should show the
> exact byte size. Apple has done it completely in reverse of what it should be.

I think showing it as a readable size ("1.7 meg") is reasonable. Showing it 
as "size in bytes" and "size on disk" are fine too.

>   Yeah, start doing that to a dozen files, rather than seeing it in one
> glance in the file listing. It *is* extremely inconvenient.

If I want the total, I pick a dozen files and say "properties" and it tells 
me the total. If I want to compare some in one window with some in another, 
it's mildly more tedious. I might even have to open a shell script or 
something. But even as a nerd, I don't do that too often. Mostly after doing 
a download, to make sure I got all the bytes.

>> You're bitching that a nerd feature is convenient in Linux and not Windows? 
>> You're a nerd. Exact file sizes are important to programmers, not users.
> 
>   And that's why they just *can't* include an option somewhere to turn on
> showing exact byte sizes? "Hey, it's a nerd option, we must not include
> such a thing! Heaven forbid if we start appealing to the nerd users!"
>   I ask once again: What exactly would be the *problem* here?

No, they *can* make that possible.  You're not their target audience 
(namely, a nerd who doesn't program Windows).  Hence, they haven't 
implemented it. They spent their time on other things.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message