Reboot your computer to clear up any transient conditions.
Are the photos still in the folder and of a normal-looking size?
It sounds like your hard-drive or other computer hardware may be failing or something is intervening between programs and the files that is making them unrecognizable.
Are these photos on an internal drive, a USB-drive, or a network drive?
I have them on two drives, one a backup. I just went to the backup and it did the same thing! Before the loss of the data, the thumbs showed that some had been processed in ACR.
At first I was concerned that my Edit drive was going bad as it is a new HDD, but the files are from last March and hadn't been opened at all on the backup until now.
Reboot etc to no avail.
XMP is called Adobe Extensible Metadata Platform so is there a method to open the .xmp and examine it?
The XMP sidecar is (almost entirely) a text file.
Try copying an NEF to another named file without a corresponding XMP and see if you can see a thumbnail. If not, then the NEF, itself, is likely corrupted. Maybe you did this already and I didn't catch it.
Also, if you want, upload a file and its xmp sidecar to dropbox and post a link, here, for someone else to test, on their system, to see if it is corrupted, somehow—if you can’t determine anything by looking at the XMP information, alone.
Yes, after posting I tried to open it in Word Pad. No dice. A different folder that does run will open xmp in WordPad. This is not good. Obviously, if the file will open even momentarily, as it did in both drives, xmp was present and readable but then rendered ???
It shows about 6 to 7 kb as the file size.
These particular images are of no consequence, but that's only an accident at this point.
Are the images ok and just the XMP bad, or are the images, bad, too? I’m not sure what you’re saying is 6-7KB.
Are your backups continuously synchronizing from the source folder, so corruption a long time, ago, would have been replicated?
Bad news…both files on dropbox (and presumably your hard-drive) are entirely filled with nulls/zero-value-bytes, so the images are gone, too. You might move the hard-drive to a different computer and see if something comes back to life.
I used this hex-editor: http://download.cnet.com/HxD-Hex-Editor/3000-2352_4-10891068.html
Thanks for the link. I concur with your findings. The question still remains, wha' happened to the data? Something erased it both. If I saw the image only momentarily, Photoshop opened it ok but then the data erased or was replaced with zeros.
Suggests a virus? I did a virus check immediately upon seeing this failure.
Was the momentary image something you saw in Bridge, from the Bridge cache, or did you do a direct PS File / Open, and see the image and then it somehow disappeared on the screen while you were watching the PS workspace?
Is this an external drive, a secondary internal drive, or a primary boot drive?
If the entire hard-drive were zeros then the directories would also not have any data in them and it would look like a new hard-drive, so if something is actually wrong wtih the hard-drive then it is only a patchy problem, not that the hard-drive is completely dead--you arleady know this becaseu you've found other files that are ok.
How does the backup have bad files on it? Have they been bad for a long time, or just now?
I saw it in Bridge, not PS workspace.
It's on 2 secondary drives; an Edit drive and it's backup.
I suspect the backup simply picked up the change in that folder some time in the past. The script checks each folder for changes and rewrites the data if necessary with the current data. So the repeat performance at the backup level isn't such a surprise after all.
I'm off to bed soon. I'm running Sophos Virus over night. All drives. It's slow but effective.
I've deleted the file from dropbox as Windows Firewall blocked access to this file from a Public Terminal, indicating someone tried to access it that way. Since we know what's in that file now,(nothing!) there is no need to let it continue in dropbox.
I suspect that a forum like this could be a source for access to those who have ulterior motives.
No problems found by Sophos. I will continue looking and any comments appreciated.
I don’t think WFW would know about any outsider accessing the file on dropbox since it runs on your local computer. If this is the first time you’ve used dropbox, it may have been asking for permission for dropbox to access your local system via the public network (there are local, domain and public tiers in the firewall rules) since dropbox synchronizes things between computers via the data stored in the dropbox cloud storage.
In other words, I downloaded the file to my local computer using the public link you provided, and wasn’t logged in as you, so would have been accessing the dropbox cloud for retrieve the file but not be logged in as you, but I don’t think the WFW would know I was doing anything for that interaction because that is between me and the cloud, not something on your local computer. Depending on how you answered the WFW question, you may have blocked dropbox from doing its normal things. You can get into the WFW configuration in Admin Tools (or maybe Control Panel) and enable things for a particular program that you may have disabled by mistake.
Back to the corrupted file issue: spot-check a few of the bad files on the backup, right-click Properties, and look at the Created Date and Modified Date, compared to the expected date the backup first would have copied them, to see if either indicates the date the zeros were written. You might want to compare those dates on files that are ok, to see if there is some difference in pattern. It is possible the backup software updates those dates to be what the source files dates are which might mask the backup-software's last-copy date, which is what you want.
If you can determine the date for the zeros and it is fairly recent, then the system event log might list something as having occurred.
If there haven't been any viruses, then I'd say it was a transient condition, either in the circuit-boards or cabling or the hard-drive media, itself.
Has the computer ever locked up so you had to turn the power off to get control back of the mouse?
You can test the hard-drive media for errors by chkdsk d: /r or chkdsk d: /b (or the gui-scandisk equivalents) to scan for data errors--iffy media problems. Move any virtual-memory swapfile off that drive if you want to test it while the computer is running. Maybe do a plain chkdsk, first, one where you don't fix problems and don't test the media, which would find problems indicated with zeros in the directory-structure, first. And if you find any of those, disconnect your backup drive in case the "fixes" corrupt even more things and that gets replicated.
A chkdsk that fixes media problems will likely take several/many hours.
Not the first time using dropbox. You accessed the file with no flags here until this morning when the computer woke up after your access.
This computer recently reverted to Balanced Power mode w/o any input from me so I am beginning to really be concerned. The backup is in an HDD plugged into a removable tray via sata which I have to activate via a physical key. I've used it this way for 2-3 years now. It is deactivated at the present moment.
I could not find an event which recorded the switch to balanced mode.
Major search of events logs show no anomalies over the period Dec 7 to present. Dec 7 was the last date I updated the backup. There is a big difference with the effected folder's dates and everything else, but that may be because I am dealing with that folder.
The only outstanding difference is no Bridge cache whatsoever in the bad folder. So i suspect I'll need to do a search of all the folders for the presence of a cache. But in any case, simply a deleted cache should not result in a corrupted file.
I would like to know if one does have either file (.nef or .xmp) corrupted to this extent, will that result in the other file being also corrupted? IOW, supposing the .xmp becomes corrupted? What will result when accessing that corresponding nef?
Is the corruption experienced here rare or not? What likely form would a corrupted file take other than complete loss of data?
What are the Created and Modified dates of a backup copy of one of the all-zeros XMP and NEF files? (Momentarily engage your backup drive to look), and what was the taken-date of the file, as best you can judge?
I am assuming these files were zeroed out long ago, and replicated to the backup long ago, at any time between when Bridge last built its thumbnails (which you saw momentarily) and now, and it is only your discovery of them being corrupt that has occurred recently, or are these files taken in the last few days, so the damage would be recent?
As far as no bridge cache, maybe your bridge-cache was centralized at the time you last visited the folder, or maybe the bridge-cache file is deleted once bridge doesn’t see any valid image files, which would have happened yesterday when you momentarily saw images, then the icons changed to NEF.
I’d guess this corruption has nothing to do with Bridge or Adobe and more to do with your hard-drive or other hard-ware, and could happen to any files on your computer or drive, depending on where the problem occurs.
Not so long ago, ssprengel. Dec 7 to be exact. That's after I transferred files from an old HDD Edit to a new drive, and that's where the problem seems to be centered; the transfer from the old to the new. So, I just happen to have the old Edit drive available with that file intact. I deleted the offending file and installed the version from the old drive and everything came back.
So essentially you are correct. It is an accident that isn't centered on the file being what it is here. It can happen with any corrupted transfer.
Lucky I didn't trash the old drive.
I did learn a few more things along the way, particularly after examining the folder's data on the hex editor, along with some experimentation. For openers, the need for .xmp files is not there to simply open the image in ACR/Photoshop. Because they exist upon downloading the camera data, I assumed they were necessary. They are not. If one opens a folder containing just the .nef in Bridge, you can see the thumb and if desired, the Preview. Closing it does not generate the xmp. It generates once the file is tweaked in ACR. Which begs the question: Why have 400 .xmp files generated when downloading 400 images from the camera if they are not necessary for the .nef to open?
The key to whether the nefs will open lies in the information on the right side of the columns from 00 to 0F as seen in the hex editor. That those columns are all zeros doesn't mean there is no data, as is evidenced when looking at the file in Win Expl. There one sees 12MB showing for a file size, a file of all zeros in the reader.
Thanks again SS and I hope others gained an insight or two.
"There shall not be no HDD trashing before it's time"