Trouble of the Day
-
-
A Former User last edited by
Hi there!
Yesterday several files of mine here wouldn't open. They show in the folder, no different icon (video), they show their file size and file name, and last edit; but they have appeared to lack their Properties - you know, file's "metadata" on right click and then some. When I tried to have them open - as usual - the player opens then says "file not found".
The files in question had recently been moved into a new folder in a larger folder having been itself moved from Disk C to Disk D.
Also I regularly clean junk with my AV's clean-up plugin with no problem so far, and I had just done defragmentation on Disk C - after moving the larger folder to D.
Well, refreshing the folder with the files didn't make any difference, haven't tried rebooting the computer yet.
In that folder, like many files were like that, while some others looked fine and played fine. Forgot to mention: tried deleting such a file - the system says "error" and doesn't it seems.
I tried to figure out what action(s) of mine could trigger such a thing, but couldn't find any pattern: some files had been moved one way, some others another way, perhaps even there are some with a third way. Like moving with the mouse, or using the folder menu on the left...
File system shouldn't differentiate of those, right?
Why "not found" when the files shown and their sizes shown? Some fragments missing? How? Defragmentation? Cleanup? Moving error? -
blackbird71 last edited by blackbird71@joshl The way a file system works is that the files themselves are stored on a storage drive (hard disk, flash, SSD, etc), but the primary metadata regarding them is created and stored in a special area of the file system itself and acts as an index to the files on the storage medium. Windows file explorer contains functionality to view the metadata in the file system index when you right-click a file name and select "Properties". When an app or user tries to open a file, the system uses the file system's indexed metadata for the file name to retrieve it into RAM from the correct storage location. If the metadata in the file system index becomes corrupted or parts of it get deleted, the file system may become unable to determine and connect to the file in its actual storage starting location, though the index may still contain some readable metadata regarding certain of the file's details. A variety of things can corrupt the file system index: a failing drive, a crashed or interrupted file copy/move operation, corrupted file defragmentation, a malware attack, an erratic drive controller, and so on.
An analogy is that the metadata file index is like a book's topical index. If the book's page index has become corrupted or had some information deleted, you can't use it to locate the pages where certain sought information is still located. The affected files (or perhaps parts of them) are likely still in existence on either the original or the secondary drive, but the system index has lost track of them.
There are disk recovery tools that can sometimes scan through a storage drive and reassemble missing/broken files from their scattered and unindexed pieces, but the results will sometimes be incomplete or spotty if the disk has sustained a lot of write activity from usage or from defragmentation after the index corruption occurred. Depending on the nature of the original failure, the drive sectors may be marked as 'available' and get over-written and incorporated into unrelated files.
In any case, you face two issues: determining what caused the failures in the first place (since if it's failing hardware, it will only get worse), and trying to recover the affected files (if necessary). From your original description, it seems quite possible that the original attempt to copy the files into a new drive/folder may have been incomplete/defective and corrupted the metadata for those files.
-
A Former User last edited by
@blackbird71 said in Trouble of the Day:
From your original description, it seems quite possible that the original attempt to copy the files into a new drive/folder may have been incomplete/defective and corrupted the metadata for those files.
Then how to proceed in this case?
If it's an occasion corruption of these few files, like due to your said copy error, the problem is to either recover the files or delete them.
If it's possible to recover them, what would the method be? Well, only if it gives a good chance with minimal side effects, because I'd rather clear the mess altogether by deleting them.So, what would cause this copy error? Some system/hardware malfunction?
Will it get worse? Can I deal with it? -
blackbird71 last edited by blackbird71
@joshl If it were me, I'd first check Windows Event Viewer to see if there were any reported errors that have occurred (particularly around the time when the copying was performed) which point toward the file system and/or hard drive(s) on my computer. If I had any drive-checking or file-checking tools, I'd also use them to make sure the drive(s) is not failing sporadically. Either a failing drive or a corrupted system file can make any subsequent recovery effort pointless. System File Checker may be able to repair corrupted system files; failing drives should be replaced.
Then I'd try to recover the lost files from both drives using a free tool like Piriform Recuva ( https://www.piriform.com/recuva ) or
IObit Undelete ( https://www.iobit.com/en/iobitundelete.php ). Note: a risk exists in that the more files you write to the drive that actually contains the file pieces in question, the greater the chances of over-writing any file portions that may have been marked by the os as 'available', but there's little way to avoid the risk if you need a place to install the recovery tool(s). Most recovery tools methodically "walk" through a drive itself and try to piece together files whose portions they find, regardless of what (if anything) is listed in the file system index. (This is possible since a file stored on a drive typically is broken up into myriad small pieces, the last few bytes of each of which are a vector pointing to where on the drive the next file piece can be found). If all the pieces are still valid and in place, the file can then be recovered... if some pieces are missing, the recovery will either fail or the result will be incomplete/corrupted.'File errors' can occur for a lot of reasons. If the file system index is messed up, the operating system may not be able to find the requested file in storage for the name in the listing, and depending on what information is missing/wrong, the error message may vary. If the index metadata is correct, but the file itself is hopelessly corrupted or pieces of it missing, various error messages may also be issued. Much depends on the specific error message issued for a particular action that was attempted.
-
A Former User last edited by
@blackbird71 said in Trouble of the Day:
I'd first check Windows Event Viewer to see if there were any reported errors that have occurred (particularly around the time when the copying was performed) which point toward the file system and/or hard drive(s) on my computer.
Is this it?
How do I make it show me something?? -
A Former User last edited by
@blackbird71 said in Trouble of the Day:
If I had any drive-checking or file-checking tools...
Like what?
If I open "My computer", then right-click on a disk, then "service", there are a few options. Is it like that? "CHKDSK"? Done a few times, each time it just bored me for more than an hour then nothing other than usual. Should I get my laptop X-rayed or something?
-
A Former User last edited by
@joshl said in Trouble of the Day:
If I open "My computer", then right-click on a disk, then "service", there are a few options. Is it like that? "CHKDSK"?
Had already scheduled and just did that. Full for C and "halfway" for D.
I do not exactly get it. If something's wrong, will a "warning screen" of sorts be lingering just a little longer than that couple of seconds?
For the latter checking of Disk D, it kinda did it as it seemed, then a little window said "Check finished" and that was it. The little window was kinda blue and with no warnings in it...Well, if I may a couple of relevant questions...
- When I went to reboot, there was a "can't close" warning window there talking about some
rundl.exeif I cite correctly. It said "data could be lost", I proceeded anyway. What was that? Could it be relevant to my recent problem here? - After the reboot etc., I used my AV's clean-up plugin to like "sterilise" the space. Yes, it found some "Windows junk" there! After the reboot with full CHKDSK and checking Disk D.
Well, the question is: there was some 9MB in "Windows prefetch files". I had had it unchecked previously - because I didn't know what it is and the name sounded like it mattered... Did it? I did check it this cleaning time, in case it mattered. Is it important?
(Haven't checked those troubled files yet, after the reboot and co. Am going to.)
- When I went to reboot, there was a "can't close" warning window there talking about some
-
blackbird71 last edited by
@joshl Assuming you're still on XP (?), there typically will be three categories of data in the event viewer: Application, Security, and System. The last (System) is probably the best place for error messages related to your original problem. Since my Russian-fu is weak, your equivalent term may be the third item in your posted image, above the Internet Explorer entry. Highlight that one and you should be able to scroll through a chronological list of all the events recorded for the 'system' category... you're looking for yellow warning or especially red error icons and entries at or just prior to the file-copying date/time when you tried to initially copy your now-problematic files. You may otherwise find a scattering of irrelevant errors across the log... a lot of Windows installations toss up a few unimportant errors from time to time.
Chkdsk should be adequate for a drive/file-checking tool. Ordinarily, you should get a 'results' message after completion which reports at least an exit code, if not a textual 'results' message (0=no errors, 1-errors were found and fixed, 2=disk cleanup performed, 3=could not check the disk or errors could not be fixed because fixing was not specified). In running chkdsk, what did you select regarding possibly fixing errors or whether to recover bad disk sectors?
Prefetch is a Windows folder containing files that each refer to an application program on the system and which store a variety of app usage information used to speed up the loading of the program in future operations. Normally, users should leave them intact to get maximum system performance, but in cases where uninstalled programs left pieces behind, there may be some unneeded files that accumulate there and can be weeded out. Routinely cleaning prefetch is not considered wise by many gurus, since some applications may have very slow startups without prompting from prefetch data. If you're not going to use prefetch, it's far better to simply turn it off in Windows than continually clean out the files.
-
A Former User last edited by
@blackbird71 said in Trouble of the Day:
@joshl Assuming you're still on XP (?), there typically will be three categories of data in the event viewer: Application, Security, and System. The last (System) is probably the best place for error messages related to your original problem. Since my Russian-fu is weak, your equivalent term may be the third item in your posted image, above the Internet Explorer entry. Highlight that one and you should be able to scroll through a chronological list of all the events recorded for the 'system' category... you're looking for yellow warning or especially red error icons and entries at or just prior to the file-copying date/time when you tried to initially copy your now-problematic files. You may otherwise find a scattering of irrelevant errors across the log... a lot of Windows installations toss up a few unimportant errors from time to time.
Yes, I am still on XP.
"Open 'System'"-- yes, I did that. I remember having already tried to use that thing looking for errors. There are two problems: 1) the general problem is that there's no meaningful data in those lines (yes, there are errors), 2) I do not remember even approximately the date of the moving -- between a week and two months, sorry. -
A Former User last edited by
@blackbird71 said in Trouble of the Day:
Chkdsk should be adequate for a drive/file-checking tool. Ordinarily, you should get a 'results' message after completion which reports at least an exit code, if not a textual 'results' message (0=no errors, 1-errors were found and fixed, 2=disk cleanup performed, 3=could not check the disk or errors could not be fixed because fixing was not specified). In running chkdsk, what did you select regarding possibly fixing errors or whether to recover bad disk sectors?
For D -- only box 1, for C -- both.
-
A Former User last edited by
@blackbird71 said in Trouble of the Day:
If you're not going to use prefetch, it's far better to simply turn it off in Windows than continually clean out the files.
How could I be going to use something I neither know what it is nor where it is?
Thank you.
No, I didn't leave it checked; it was only that one time. -
blackbird71 last edited by
@joshl I'm not sure why you're not getting a better readout for the d: drive. I suggest you try running chkdsk from an admin command prompt:
Start > All Programs > Accessories > right click: Command Prompt > select: Run as administrator (if reprompted for permission, click 'Yes' to allow program to make changes to computer)
In the black command box that opens, enter:
chkdsk d:You should then get a listing of: total disk space, number of files and space used, number of indexes and space used, space in bad sectors, space in use by system, space occupied by log file, space available on disk, space in each allocation unit, total number of allocation units on disk, and available allocation units on disk. Note: if you don't get a listing, something is wrong with the check disk operation on that disk or system.
If the disk shows bad sectors or other problems in the listing, rerun it with the /R command 'repair' option:
chkdsk d: /RThis will check the entire d: disk surface for bad files and bad disk sectors and attempt to repair them (or, in the case of sector problems, to copy the data and remap it into a good sector before marking the bad sector thereafter as being defective so it never gets reused).
(FYI: If you try to use the /R command for the C: drive (containing your OS), you will probably get an warning message "cannot lock current drive" and it will offer to schedule the volume to be checked the next time the system restarts. In that case, type/select Y and then reboot the system. Chkdsk will run before Windows starts up so that disk repairs can be made before Windows starts using it.)
-
A Former User last edited by
@blackbird71 said in Trouble of the Day:
Start > All Programs > Accessories > right click: Command Prompt > select: Run as administrator (if reprompted for permission, click 'Yes' to allow program to make changes to computer)
Like this one?
It was different path than you said, but similar. -
A Former User last edited by
@joshl said in Trouble of the Day:
Haven't checked those troubled files yet, after the reboot and co. Am going to.
Nothing changed, by the way...
@joshl said in Trouble of the Day:
@blackbird71 said in Trouble of the Day:
Start > All Programs > Accessories > right click: Command Prompt > select: Run as administrator (if reprompted for permission, click 'Yes' to allow program to make changes to computer)
Like this one?
It was different path than you said, but similar.Risked doing that - "Командная строка". Entered
chkdsk d:thenEnter.
Well, right away it said something like "parameter 'F' was not specified, so it'll be only reading" or something. What is that "F" parameter?@blackbird71 said in Trouble of the Day:
You should then get a listing of: total disk space, number of files and space used, number of indexes and space used, space in bad sectors, space in use by system, space occupied by log file, space available on disk, space in each allocation unit, total number of allocation units on disk, and available allocation units on disk. Note: if you don't get a listing, something is wrong with the check disk operation on that disk or system.
Well, I did get a listing.
Maybe because of this lacking F parameter, the list appeared shorter than it seemed to occur according to the above quoted piece of yours...
However, it said like "stuff in damaged sectors - 0".Can one copy text from there?
(Or I could "PrtSc", can I? In case it's needed...)Thank you again!
Oh, what was that
rundl.exenot closing upon commencing the reboot I asked you about? Just in case it's relevant...
Or important.
-
A Former User last edited by
@joshl said in Trouble of the Day:
Oh, what was that rundl.exe not closing upon commencing the reboot I asked you about? Just in case it's relevant...
Googled that.
Google said it was two ls.
Found some information here.
Unless it's relevant or important, let's discuss it in my "Search tubs" thread:D -
A Former User last edited by A Former User
@joshl said in Trouble of the Day:
Risked doing that - "Командная строка". Entered chkdsk d: then Enter.
Well, right away it said something like "parameter 'F' was not specified, so it'll be only reading" or something. What is that "F" parameter?blackbird71 said in Trouble of the Day:
You should then get a listing of: total disk space, number of files and space used, number of indexes and space used, space in bad sectors, space in use by system, space occupied by log file, space available on disk, space in each allocation unit, total number of allocation units on disk, and available allocation units on disk. Note: if you don't get a listing, something is wrong with the check disk operation on that disk or system.Well, I did get a listing.
Maybe because of this lacking F parameter, the list appeared shorter than it seemed to occur according to the above quoted piece of yours...
However, it said like "stuff in damaged sectors - 0".
Found that too.
Did that - with/f. The list was with 7 lines in it, then some; no warnings or reports of "curing errors", zero in 'damaged sectors'.
Should I now /r that?:) -
blackbird71 last edited by blackbird71
@joshl The F parameter with chkdsk directs the chkdsk process to repair (if possible) any defective file it finds. Not specifying a parameter simply gives you results of the chkdsk analysis of files on the disk without fixing anything or surface scanning the drive. If one uses the R parameter, the process both repairs defective files and scans the drive surface for defects and moves all files in bad disk-surface sectors to good sectors, then marks any bad sectors as such in the OS's file tables so they don't get reused in the future. Because I don't know the original condition of your d: drive (used, new, etc), I thought it useful to make sure bad sectors aren't involved in your missing/partial files problem, hence my suggestion for using the R parameter to check anew for failed sectors (a potentially likely issue on an old disk). The R parameter does take significantly longer to run than an F operation, and probably wouldn't be needed for a brand new formatted drive. When you run chkdsk using the MyComputer, services method, the boxes you check act to supply these various parameters as appropriate. I suggested using the command line method for chkdsk to make sure the MyComputer/services mechanism within Windows wasn't itself problematic on your computer... when in doubt, I prefer to use the most basic control mechanisms possible.
From the report you got on c: with "both boxes checked", it appears likely that any files that were repairable on that drive should now have been repaired; for the d: drive, there may still be a question about surface conditions if it's a used drive. In any case, after using chkdsk (F or R) on both drives, if your missing files are still missing, then they're probably only retrievable (if even then) by using a recovery tool as I noted earlier. If the problem arose from a messed up or interrupted copy/move operation, then the files may have been hopelessly lost or corrupted along the way.
Rundll.exe is a Windows program that launches the functionality stored in a .dll file. Multiple such processes may typically be running on a Windows computer. It's normally a legitimate process as long as the running rundll file is located in \windows\system32 (malware sometimes tries to fake the name and run from other attackable locations). In Task Manager, if you go to View\Select Columns, you should find "Command Line" in the list and you should check it. This will then show the full path for the files in the list. In the case of rundll, it will show you both where the rundll file itself is located and where the DLL file that is being run by rundll. When you got the earlier warning message as you went to reboot, it meant that a rundll process was still running its .dll file and wasn't closing gracefully in order to reboot. Not knowing the related .dll file involved, it's only a guess as to what was occurring. My best guess, assuming you don't get such a message each time you reboot (which would indicate something is consistently "hanging") is that part of whatever you were doing (chkdsk?) had not registered with the system as completing its operation for some reason when you went to reboot, hence the warning.
-
A Former User last edited by
@blackbird71 said in Trouble of the Day:
Because I don't know the original condition of your d: drive (used, new, etc), I thought it useful to make sure bad sectors aren't involved in your missing/partial files problem...
From some time ago, I got that my C and D here are just equal logical partitions of one single physical drive...
(Released from hospital the other day; not too comfortable...)
-
blackbird71 last edited by
@joshl OK. I had assumed the d: drive was a physically different piece of hardware - I hadn't considered it as being a separate partition on the same physical drive as c:. The possibility of surface problems on a second physical drive was why I raised the earlier question. With both partitions instead living on the same drive, the odds are that if there aren't sector/drive issues on one partition, the same would be true for the other partition.
I certainly hope you can get yourself on the road to some meaningful healing finally... I assume it's still the arm issue?
