An oddity that's a little bit scary...

May 24, 2010
855
0
Northlake, Il
As I usually do an unmodified partial log of a TCC session:
Code:
 Directory of  X:\Obsolete Music Files\z*

 7/20/2014  1:30  0  zia10224
  0 bytes in 1 file and 0 dirs
 1,407,083,044,864 bytes free

[X:\Obsolete Music Files]del zia10224
Deleting X:\Obsolete Music Files\zia10224
  1 file deleted  1,182,859,264 bytes freed
Presumably the question is obvious. How can deleting a file whose length is zero free 1,182,859,264 bytes bytes (more than a gigabyte!)?
 
Nov 13, 2008
257
3
www.thedave.me
If I recall correctly, it doesn't actually keep track of the space freed, but rather, it does a comparison against the free space at the start and end of the operation. This leaves plenty of room for oddities.
 

rconn

Administrator
Staff member
May 14, 2008
11,005
98
Quick question: should the "before and after" behavior be the proper one (... at least for single file deletion)? After all, it's not like the system can't tell exactly how many sectors a certain file occupied.
TCC used to do that -- and I got hundreds of complaints from people who said that DEL told them they freed memory when they didn't (because Windows was deleting to the recycle bin or similar third-party app). The current solution was deemed the least confusing and apt to generate "bug" reports.
 
May 24, 2010
855
0
Northlake, Il
Thank you guys and I believe you. But it is a little bit strange that something of that magnitude can happen in the time it takes to do a delete of a single zero-length file!
 

rconn

Administrator
Staff member
May 14, 2008
11,005
98
Thank you guys and I believe you. But it is a little bit strange that something of that magnitude can happen in the time it takes to do a delete of a single zero-length file!
Not really -- there's usually an enormous amount of activity going on in the background. Text indexing, incremental backups, temp file cleanups, disk optimization, journaling, etc.