Funny because it's true.... | The Coffeehouse

fabian

LeoDavidson

Heh. Smiley I don't use/see the windows (shell) file copy stuff much but I still wonder, after almost three years with Vista, what the heck is going on when deleting a file to the recycle bin sometimes takes a minute or more (and sometimes is instant).

(Maybe it's triggering an anti-virus re-scan of the file or something? I'll have to pay more attention to the filetype next time it happens. Perhaps it's always large exe / archive files that trigger the problem and I've never made the connection before.)

spivonious

In reply to LeoDavidson

#Aug 3rd @ 8:10 AM

Sometimes file operations take a little bit to get started for me because my second hard drive has spun down. Maybe that's it?

That comic is hilarious.

LeoDavidson

In reply to spivonious

#Aug 3rd @ 8:18 AM

My HDDs are set to never power down so it's not (only) that for me.

ManipUni
Proving QQ for 5 years!

<Devil's Advocate>

Having an inaccurate estimation is the least bad of two evils. The other alternative is to add a large amount of time to copies while the OS polls all the files.

</Devil's Advocate>

If the NTFS filesystem was mirrored in memory you could get maximum copy speed AND accurate estimations. You could also look for blocks of data within the sub-directories and do a larger, faster, read instead of random-reads.

PS - Why isn't "filesystem" a word?

littleguru
<3 Seattle

I could argue: first you could be in heavy traffic, then in a dramatic jam and then no traffic because you exit the freeway Tongue Out

TommyCarlier
I want my scalps!

In reply to littleguru

#Aug 3rd @ 10:35 AM

That would be a very dramatic jam. I see that your MS employee chip has already been implanted. Wink

Ion Todirel
buuu

In reply to ManipUni

#Aug 3rd @ 10:21 AM

Then the whole system will brake lose when you copy something from somewhere that's not in memory, plus there will be a cost of copying stuff in memory. Will you copy the things in memory first, wait, then copy between memory? Or copy from a disk to another while syncing the memory at the same time? Not to mention possible performance implications and the cost of a multi TB RAM array.

ManipUni
Proving QQ for 5 years!

In reply to Ion Todirel

#Aug 3rd @ 1:43 PM

You have the file system in memory, not the data... There are no "things" in memory. Only references to "things" that are contained on the disk.

File Structure, Size, and start location. That's all you'd need to both create accurate estimations and also to look for more efficient ways to copy large blocks instead of random-reading files one by one.

PS - A lot of the questions you ask are already answered by NTFS's journal design.

Heywood_J
Trust me, I'm from the Internets

In reply to ManipUni

#Aug 3rd @ 10:21 AM

"Having an inaccurate estimation is the least bad of two evils."

Actually, there's no need to be stuck with the least of two evils. Instead of stupidly trying to display how much time a copying operation will take (and almost always being wrong) -- why not simply display:

copying xxx bytes out of yyy

or

copying xxx files out of yyy

littleguru
<3 Seattle

In reply to TommyCarlier

#Aug 3rd @ 10:57 AM

Actually no. Tongue Out Still waiting for my implantation But it's hard to predict the future properly... that's my point. Smiley Copying stuff includes a lot of stuff that you can't predict when you start... isn't that true. Nevertheless the dialog time shouldn't jump around that much, as it does...

Sabot
My name is Dave Oliver. I'm a Technical Architect.

In reply to littleguru

#Aug 3rd @ 9:57 PM

Just an observation, I seem to get more accuracy when I use better storage, such as the RAID 5 NAS than say the USB stick.

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to ManipUni

#Aug 3rd @ 1:47 PM

You have the file system in memory, not the data...

That's still going to require a lot of memory. I just checked, the MFT for my C: volumes is 200MB (you can find this out on Vista/7 by running "defrag C: /a /v"). I have 5 volumes in total, and the MFTs of the others are around 100MB in size (it depends on the number of files on the drive more than anything else).

So keeping the entire MFT in memory for all my volumes would cost me about 500-700MB of memory. That's a rather substantial cost just to get better estimates of file copy times. Especially since this memory would have to be non-pageable, because that would defeat the purpose.

AndyC

In reply to Heywood_J

#Aug 3rd @ 8:57 PM

why not simply display:

copying xxx bytes out of yyy

Because real people don't care how many bytes or how many files have been copied. They just want to know if it's going to finish before they have to rush out of the office.

Heywood_J
Trust me, I'm from the Internets

In reply to AndyC

#Aug 4th @ 3:51 AM

Because real people don't care how many bytes or how many files have been copied. They just want to know if it's going to finish before they have to rush out of the office.

??????? So you are saying "real people" are too stupid to look at something like "copying 20 files out of 40" and figure out that it's half done????

AndyC

In reply to Heywood_J

#Aug 4th @ 6:15 AM

"??????? So you are saying "real people" are too stupid to look at something like "copying 20 files out of 40" and figure out that it's half done????"

Except it's possibly isn't. If the first 30 files are 10Kb and the rest 400Gb then it's woefully short of halfway through at that point. And, again, people don't care about "halfway" they care about "What time will this finish?", "Should I wait or should I go for a long lunch?" etc.