Darren New <dne### [at] sanrrcom> wrote:
> >   So in order to get Windows Explorer to show exact byte counts, I would have
> > to download and install Visual Studio, get it to work, write an extension
> > manually, install it, and keep it with me in an USB stick so that I can
> > install it in a friend's computer if I ever want to see the byte sizes there
> > as well?

> Pretty much, yah. Same as any other program you write. What did you expect?

  I expect Windows to support such a *basic* feature as showing the sizes of
files in bytes. It's not like it's too much to ask. I'm sure someone at MS
could add the feature in 5 minutes. In fact, I wouldn't even be surprised
that they *already* have the feature but it has been disabled with an #ifdef,
so all it would take to support it is one additional #define.

  But they don't. Why not? I have no idea.

> You mean if I want to indent files the way I like, I have to download emacs, 
> write some elisp code, then stick it on a USB stick and carry it around to 
> every other emacs-enabled computer?

  Yeah, because indenting code is in the exact same league as showing file
sizes in bytes rather than rounded.

> >   I think you made some kind of claim containing the word "trivial" in some
> > post of yours.

> More trivial than rewriting the shell. A 50-line program is pretty trivial, yes?

  No. Trivial is "click here and here, and you are done".

  You have a rather odd definition of "trivial". It still sounds like "not
impossible".

> >>>> 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?
> > 
> >   You are nitpicking, and you know it.

> You're nitpicking. You want exact byte counts in one window but not the 
> other.

  What? What window? What other window? I have no idea what you are talking
about.

  The only thing I want is an option somewhere that, when checked, will make
Windows Explorer to show file sizes in bytes instead of rounded to kilobytes
or megabytes. That's it. Nothing less, nothing more.

> It's trivial to get that information

  I don't want to "get that information". I want Explorer to use bytes when
listing files and their sizes. "Getting" is too laborious. I don't want to
"get" anything, I want it to show it without me doing anything to "get" it
explicitly.

> yet you complain it's difficult.

  It's extremely inconvenient and slow. I want a full list of a directory
with file sizes in bytes. That's all. I don't want to have to open some
separate info dialog on every single file just to see the size in bytes.
That's just crazy.

  It's not like it would be away from anybody. If someone doesn't want to
see the sizes in bytes, he just doesn't use that specific option. It's that
simple.

> Plus, you can't even clearly define what it is you want to see.

  You know *perfectly* what I mean, so stop acting stupid. You are just
arguing for the sake of argument.

> > Is agreeing with something really so hard?

> I already agreed. You kept bashing at it.

  "you can't even clearly define what it is you want to see" doesn't sound to
me like agreeing.

> >   So if I want to see the individual byte sizes of 20 files, exactly how do
> > I do that "with one extra step"?

> "dir"

  You have an odd definition of "one extra step".

  Pressing the keys 'd', 'i', 'r' and return is certainly not enough. There
are quite many additional steps involved, including going somewhere else than
Windows Explorer.

> >   Each file in a list having its size shown with a different unit is
> > confusing. You can't visually see which of the files are larger and
> > which ones are smaller. 

> Click the size column header and it sorts by size.

  That doesn't give me visual feedback on the sizes of the files. It only
tells me which files are larger than the others. It doesn't tell me how
much, unless I start deciphering the units one by one.

> >>>   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. :-)
> > 
> >   The amount of bytes in the file. What's so damn hard to understand about
> > that?

> OK, now I ask you "how big is the directory? What's its size? How many bytes 
> in that Linux directory? What's so damn hard to understand? I just want to 
> know how many bytes are in it."

  I'm not interested in the size of a directory. I interested in seeing the
sizes of the files in bytes, that's all.

  (Seeing the total size of the files in bytes without having to do anything
extra to get it is useful as well, but a somewhat different issue.)

> "How big is that process? How many bytes does it take in memory? What's so 
> hard to understand about that?"

  I'm not interested in that in this context.

> Copy the file to another system or an archive file. That's three different 
> sizes. Copy the file to another file system may or may not lose the 
> compression. Copying it to an archive file is going to need it to carry the 
> encryption and ACL overhead as well as alternate streams. That's exactly my 
> point.

  So what? I'm not interested in how much disk space the file is taking.
I'm interested in its size in bytes. If disk usage is what one wants, *that*
can be put in some info dialog or whatever you want.

> >   The amount of bytes in the file. What's so damn hard to understand about
> > that?

> Because first you ask for the amount of bytes in the file, then you ask for 
> the amount of bytes you'd read if you opened and read the file. And that's 
> two different numbers.

  Why do you keep nitpicking? You understand perfectly what I'm talking about.

> >>>   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.
> > 
> >   Do you have reading comprehension problems? I was not talking about totals.

> The "that" wasn't really clear there. "Start doing that to a dozen files" 
> doesn't really say whether you mean "one at a time" or "all at once."

  If Windows Explorer showed sizes in bytes for each individual file *and*
for the total (in the status bar), then it would solve both problems at
once, without the need to open any info dialogs. See? Easy.

> I'm not defending Microsoft per se. I'm just saying you seem to think 
> there's some big important reason for this feature not to be here.

  Well, I have yet to see a good reason for it to not to be there.

  (Except Microsoft's incompetence. This is certainly not the only
annoying feature which worked ok eg. on Windows 3 but MS decided to
screw it up for newer versions just for the sake of making it different,
even at the cost of making it usable.)

> I just 
> think it's that it didn't sell more copies of Windows. There would be no 
> downside to providing it except the need to spend resources providing it.

  There are tons of way more useless features in Windows than this. Features
which almost nobody uses. They didn't have resource problems for those.

-- 
                                                          - Warp

Post a reply to this message