rodalsa1

Here is the JPG of the table...

Sorry. The posting process wiped out the table structure. I'll work on getting a JPG of it and post it later. If there is a faster way let me know.

I have had Recuva flag a scan as Failed. I have terminated Recuva Scans. I have had successful Recuva Scans. I have shown all three types of Recuva scans listed in the "All local disks" drop down box as shadow copies. All I wanted to do was to either know which shadow copies were associated with which class of file (Failed, Terminated or Successful) without having to do the interpretations I have discussed. This would allow me to avoid scanning any files that were not successful. In the process of trying to find a way to that goal, I managed to delete the Failed & Terminated & Successful files that I created in the past several days. That left three unknowns that I did not want to look at again. I wanted to delete them. They were outdated and were not going away by any technique that I knew how to use. Thus my query. I remembered reading... (another copy from OneNote) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I ran across this while searching the online help… Secure overwrite does not affect file names, which continue to exist in the MFT (Master File Table). In order to overwrite names of deleted files, please use the Wipe MFT Free Space option in CCleaner. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This led me to try CCleaner Free --- Just in case there was some help there. Now! I have found a solution to my problem. CCleaner's / Tools / System Restore listed four files that looked like Recuva's list of four files. My latest Windows Backup and Restore shadow copy was an exact match Recuva drop down to CCleaner list. The other three were not.. Here is a copy of the table I generated in OneNote making the comparison... +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ These four "System Restore" points look eerily familiar. I will make a table to compare their dates and times… INDEX CCleaner Date & TIme CCleaner Description Recuva Date & Time Time Difference 1 3/12/2017 12:52:33 PM Windows Backup 3/12/2017 12:52 -00:00:33 2 3/10/2017 7:11:31 AM Installed Rapport 3/10/2017 08:12 +01:00:29 3 3/7/2017 3:17:21 PM Windows Backup 3/7/2017 16:17 +00:59:39 4 3/7/2017 9:05:57 AM Windows Backup 3/7/2017 10:06 +01:00:03 Table 29g New information is in CCleaner's Description column. I know that Index 1 is the last backup that I made. I recall that I made a special backup when Rapport was installed. Indexes 3 & 4 are unknown to me. Indexes 2, 3 & 4's Time differences [(Recuva Date & Time) - (CCleaner Date & Time)] are seconds apart around 1 hour. Compared to Index 1's time difference of 33 seconds, I cannot explain why the difference of one hour would exist. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ What did I have to lose! I removed the oldest item from the CCleaner list. I checked Recuva's drop down list. The Index 4's file was gone. I repeated this with Index 2 & 3 as a group. Now the only shadow copy Recuva lists is the one that I made yesterday. Even though I had to install CCleaner (I've gotten into trouble with this program before) I have achieved what all my palaver has been about. Thanks for pushing me onward. Now: How about the time differences between Recuva and CCleaner's listings of the same files? You never know what you are going to find in the dark recesses of computing system!

I'll add to the details above. I began a "fresh" start. I went to my network drive's folder in which Microsoft's Backup and Restore was told to place its backups. I deleted all of the folders there that contained data files. All I had left were folders. I deleted the "Trashbox". I then made a Windows backup (user data and shadow copy) of my C: drive (the only one). I ran Recuva again and opened the "All Local Disks" drop down box. It contained the same three Shadow copy files seen in the left side of my attachments above plus the backup that I just completed. I have no idea where these three Shadow copy file originated. I want to somehow have Recuva report to me only the Shadow copies that exists in my specified backup location or allow me to locate all Recuva's reported Shadow copies' paths as well as the status of those copies either "Failed" or "Terminated" as appropriate. Knowing were the files reside should allow me to go there and delete as desired and get on with my day. One "assumes" that since Recuva can find these drop down listed files, some program created them. I have used over time several backup programs in evaluation mode. I went back to each of them that I can recall and still have access to and made an attempt to delete any output they may have deposited on my drives. Remaining here are "those" that may have been installed and removed and their residue.

I have Recuva free V. 1.53.1089 (64-bit). All shadow copies were created using Windows 7 Pro via Backup and Restore / Create a system image. The "failures" precise causes I cannot specify. In my composite screenshot (see updated attachment below) the left pane's three entries under "All shadow copies" were present before my attempts to produce the "Shadow copy of drive (C:) 3/7/2017 15:17" seen in the right pane. Between the 3/6/2017 13:34 shadow copy in the right pane and the 3/7/2017 15:17 shadow copy you will find the four "failures" that I am referencing here. There are two groups separated by minutes within the four shadow copies shown. The time difference between the first and last shadow copies in each of the two groups indicate that the first shadow copy in the group is not a full shadow copy. It was either a error flagged by Recuva or me terminating the scan. Memory fails at 81 years of age. The second shadow copy of each group (by memory again) was a short scan. Only the second group's shadow copy produced an observed error message. I recall "red bar" failures twice. I believe the other two short duration Recuva runs were due to me terminating the scans. One of the "red bar" failures was discovered when I returned to my monitor some hours later. I expected the scan to exceed one hour as had been typical. No error messages were noted at that time as I remember it. The other "red bar" incident produced an error message telling me that there was not enough space for the shadow copy to be created. That particular error message clued me into the need to dump the trashbox. After that dump I ran the last scan seen in the right pane to a successful finish.

I understand that Recuva returns data even when the user stops an ongoing scan and the data may be of use to the user. This may also be true for Recuva's Failed scans (I had not seen evidence of this until yesterday). But what if the user is not interested in one or none of the terminated scans as I suspect most user are. I have noted that after several system image creations (Failed & terminated & a final one ... successful) the list of "All Local Disks" Shadow copies has been increased in size. See attachment. The left frame is the earliest. I attributed the increase in size to four of the Shadow copy files that I remembered as being either terminations or failures. I achieved the success by emptying the Trashbox. Can the "All Local Disks" list be color coded to specify successful Shadow copies from Failures from terminated by users or by a column with S,F,T in the proper rows? Or is there something that I via assumption am missing here?

Point taken. I should have known better. Let's rest.

I revised the jpg to a 826 KB file using a more direct translation approach. The quality is better. The bmp file was 8,572 KB. Augeas. Precisely. By presenting a work that achieves an end not present in the software I made two suggestions implicitly. #1) This site does not have a place directly suitable for the content of my thread. So why not add one? #2) Defraggler does not present the information that my work enables for those that have an interest in bytes/block. Of course Defraggler presents the total bytes/drive which is dependent on the user's hardware so my work stopped at that point. I give everyone the ability to find the total number of blocks on any Defraggler screen and Defraggler gives the user the number of bytes on their drive. The user does the math. Re graphic file translations. I tried all of the allowed translations and only the jpg came in under the file size limit. My suggestion here would be for the site to advise its users to #1) use small originals or #2) split large originals in to smaller chunks and submit multiple files or #3) the site allow larger file sizes. Hopefully your users will get messages #1) and #2) before they invest copious time building their graphics. Defraggler presents for my C: drive 124,763,471,872 as the number of bytes. It is hard to believe that Defraggler gets this number while working with file tables. I do not remember any such information being in those tables back 'in the day' when I worked directly with file allocation tables (FAT)s. I would be more inclined to believe Defraggler actually counts the number of bytes unless there is a source for that number to be found elsewhere in either the sofware or hardware installed on each computer. The drive's specifications list it as a 250.0 GB drive. C: is one of 8 partitions on that 250.0 GB drive and has a reported capacity of 116.2 GB. Ah the questions! Defraggler reports 123,763,471,872 and 116.2 GB on the same line back to back. I think 123.8 GB is more than 116.2GB! Ah the questions! Perhaps a sub-forum titled "Defraggler Technical Issues" is in order.

Thanks kroozer. I tried it. No change in quality. In fact the file size went from 519 KB to 297 KB which I usually take as a reduction in clarity. Both files were jpgs. One from me and one from CoolUtls.

Moderators. Not in the correct place? Help me out. Defraggler presents a pane on its operating screen that is called the Drive Map. This Drive Map is said to represent the entire drive that the user has selected. The Drive Map may be resized by the user and presents varying numbers of Blocks as resizing is undertaken. This obviously means that the number of Bytes per Block varies as the user resizes the screen. I wanted to know how many Blocks were present so that I could determine the number of Bytes each block represented. Try counting the number of Blocks (better yet just look at the pane) for 1 x 1 Blocks and you quickly find that there has to be a better way. There are a huge number of Block sizes measured in (x, y). The range is 1 <= x <= 19 and 1 <= y <= 19. I reduced the number to 19 by forcing x = y and obtained the results shown in the attached jpg.. I reviewed it and -- well, the jpg is there and that is about it. I had to use this site's magnifier and then use the Ctrl - + feature of Firefox to its maximum to get my font size 20 to be readable. Some of the smaller fonts that I used are not readable. Too bad I could not upload my bmp. If there is a way to make the bmp available to the viewers of this site, let me know. NOTE: The original file was created in a program named DeltaCad. In the jpg I reference the ruler that I used in my analysis. It is a shareware product (not mine). I hope that this was OK.

Right on Derek891. What I have difficulty with is why any arbitrary threshold other than zero. From where I view this there are only two changes involved. One is to change a block color. The other is to change a zero in the file list to "3 KB". What is the deep dark secret that lies in the bowels of computer hardware/software technology that mandates a threshold larger than zero? I mentioned studying another aspect of the Drive Map in an earlier post. While not pertinent to this thread, I will mention its subject and post more about it in a thread that I will name, "How many Blocks are on my screen?". There -- both the subject and the name in one question.

UPDATE: While studying another aspect of Defraggler's drive map, I noticed that white blocks (Empties) reported both empty and files when floating the cursor over different blocks. I have seen up to 63 files reported in a white block. There could be more. Clicking on the 63 file block produce both File Folder and Unknown File types all of which contained 0 KB and were identified as containing 1 fragment and a filename [Folder Entry]. So it 'appears' that my possibility #2 is the correct one. The white blocks are not empty of 'Files'. For the blocks that I observed (approximately 75) some contained actual Filenames as opposed to [Folder Entry] while 100% of them were File Folders having 0 KB size. This leads me to speculate that the color white is assigned to blocks that have 0 KB. Beyond that I navigated, using explorer, to the folder indicated for several of these 0 KB, [Folder Entry], File Folder, "Highlighted" Paths that were presented and found within that path's final folder a 3 KB file having extension *.wxl. My exclusion list was empty. So much for white blocks being empty. Now 3 KB = 0 KB. My high school math teacher is turning over in her grave -- muttering "What is this world coming to?" Someone needs to edit/add a subroutine! Rod

I was doing several consequtive free space defrags and on the last one I noticed that during the drive map update a white (empty) block would turn yellow (reading this one) during the drive map update. I then focused on this strange event and saw many more identical events. Does anyone understand this well enough to explain it to me. It appears totally illogical from here. The best that I can do is to suggest three possibilities. 1) The new read blocks are randomly chosen (low probability). 2) The blocks are not really empty but are displayed as such. 3) It is a (oh horrors) a <><>BUG<><>! Stomp. Stomp. Stomp. Rod For me to believe is insufficient for you to know. - rodalsa