File transfer stopped, now can't open any of the files

Operator · 07-22-2016, 03:57 PM

Okay, here are the ls -lc results for the parent directories

Code:

[matthewreichert@localhost Phone transfer]$ ls -lc
total 40
drwxr-xr-x.  5 matthewreichert matthewreichert  4096 Jul 18 17:50 Android
drwxr-xr-x.  4 matthewreichert matthewreichert  4096 Jul 18 17:50 bug2go
drwxr-xr-x.  6 matthewreichert matthewreichert  4096 Jul 18 17:52 DCIM
drwxr-xr-x.  2 matthewreichert matthewreichert  4096 Jul 18 17:52 LOST.DIR
drwxr-xr-x.  2 matthewreichert matthewreichert  4096 Jul 18 17:52 Move
drwxr-xr-x. 58 matthewreichert matthewreichert 12288 Jul 18 18:04 Music
drwxr-xr-x.  8 matthewreichert matthewreichert  4096 Jul 18 18:05 Pictures
drwxr-xr-x.  2 matthewreichert matthewreichert  4096 Jul 18 18:05 Videos

and here's ls -lc | tail inside the Music folder, all unavailable to open

Code:

[matthewreichert@localhost Music]$ ls -lc | tail
-rw-r--r--. 1 matthewreichert matthewreichert  6483968 Jul 18 18:03 Stardust ft Daft Punk - Music Sounds Better With You (GTA 5 Soundtrack).mp3
-rw-r--r--. 1 matthewreichert matthewreichert  4804608 Jul 18 18:03 The Company Band - El Dorado.mp3
-rw-r--r--. 1 matthewreichert matthewreichert  3653632 Jul 18 18:04 The Great Outdoors! - Clutch (Lyrics in the Description).mp3
-rw-r--r--. 1 matthewreichert matthewreichert  5283840 Jul 18 18:03 The Killers-A Great Big Sled -www.mrtzcmp3.net.mp3
drwxr-xr-x. 3 matthewreichert matthewreichert     4096 Jul 18 18:03 Various_artists
-rw-r--r--. 1 matthewreichert matthewreichert  4767744 Jul 18 18:03 WAVVES - Nine Is God [HQ].mp3
-rw-r--r--. 1 matthewreichert matthewreichert  4513792 Jul 18 18:04 White Lies - Bigger Than Us.mp3
drwxr-xr-x. 2 matthewreichert matthewreichert     4096 Jul 18 18:03 WMMR's Preston and Steve Podcast
-rw-r--r--. 1 matthewreichert matthewreichert  3420160 Jul 18 18:03 YOUNG DRO-FDB -www.mrtzcmp3.net.mp3
-rw-r--r--. 1 matthewreichert matthewreichert 11239424 Jul 18 18:03 Zoids New Century TRACK NO FUTURE(instrumental).mp3

jamison20000e · 07-22-2016, 04:14 PM

I like:

Code:

rsync

for my backups.

Not sure if it could help you now or have prevented the problem in a power failure?
I do have a couple good back up power supplies from thrift stores (similar to) but I use them for my Pi and other projects. Maybe I should put one back together?

Good luck!

Operator · 07-22-2016, 04:18 PM

I'll have to remember that... I just hope, for now, that I can get these files back. I seriously don't see what could've caused this. Maybe corrupted headers or something. The "files" are still there and named properly, right where they were. There HAS to be a way to get them back.

Operator · 07-22-2016, 04:27 PM

I just tried to open one of the images and immediately checked /var/log/messages. Here's what appeared:

Code:

Jul 22 17:25:10 localhost gnome-session: Gjs-Message: JS LOG: The property brightness doesn't seem to be a normal object property of [0x6043810 StWidget] or a registered special property
Jul 22 17:25:10 localhost gnome-session: Gjs-Message: JS LOG: The property vignette_sharpness doesn't seem to be a normal object property of [0x6043810 StWidget] or a registered special property
Jul 22 17:25:12 localhost /usr/libexec/gdm-x-session: Activating service name='org.gnome.Nautilus'
Jul 22 17:25:13 localhost /usr/libexec/gdm-x-session: Successfully activated service 'org.gnome.Nautilus'
Jul 22 17:25:13 localhost dbus[842]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Jul 22 17:25:13 localhost dbus[842]: [system] Successfully activated service 'org.freedesktop.hostname1'
Jul 22 17:25:13 localhost systemd: Starting Hostname Service...
Jul 22 17:25:13 localhost systemd: Started Hostname Service.
Jul 22 17:25:13 localhost audit: <audit-1325> table=filter family=2 entries=0
Jul 22 17:25:13 localhost audit: <audit-1325> table=raw family=2 entries=0
Jul 22 17:25:13 localhost audit: <audit-1325> table=security family=2 entries=0
Jul 22 17:25:13 localhost audit: <audit-1325> table=mangle family=2 entries=0
Jul 22 17:25:13 localhost audit: <audit-1325> table=nat family=2 entries=0
Jul 22 17:25:13 localhost audit: <audit-1325> table=filter family=10 entries=0
Jul 22 17:25:13 localhost audit: <audit-1325> table=raw family=10 entries=0
Jul 22 17:25:13 localhost audit: <audit-1325> table=security family=10 entries=0
Jul 22 17:25:13 localhost audit: <audit-1325> table=mangle family=10 entries=0
Jul 22 17:25:13 localhost audit: <audit-1325> table=nat family=10 entries=0
Jul 22 17:25:13 localhost audit: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 22 17:25:43 localhost audit: <audit-1131> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

rknichols · 07-22-2016, 04:33 PM

Quote:

Originally Posted by Operator

and here's ls -lc | tail inside the Music folder, all unavailable to open

Code:

[matthewreichert@localhost Music]$ ls -lc | tail
-rw-r--r--. 1 matthewreichert matthewreichert  6483968 Jul 18 18:03 Stardust ft Daft Punk - Music Sounds Better With You (GTA 5 Soundtrack).mp3
-rw-r--r--. 1 matthewreichert matthewreichert  4804608 Jul 18 18:03 The Company Band - El Dorado.mp3
...

It appears that you had copied/moved all those files into that "Phone Transfer" tree on Monday evening in preparation for copying them to your phone. Do you know if any of them were good after that (You said, "uhhhh... Monday or Tuesday...")? It's looking like not all of the buffered data got flushed to disk, but, if the transfer and power outage didn't occur until Tuesday, I don't know what would cause the dirty buffers to be held in memory for that long. You can look at the ctimes of the files on your Android phone to see just when you actually did the transfer and when it aborted due to the power failure ("ls -lctr | tail").

Your best bet at this point would be to shut that system down, copy an image of the entire partition or LVM volume to another disk (which you undoubtedly do not have right now), and then run photorec on that image to see what files can be recovered, perhaps from where they had been prior to moving them to this location. Anything you do with that system prior to making the image decreases the chances for a successful recovery, so shut it down now.

rknichols · 07-22-2016, 04:39 PM

Quote:

Originally Posted by Operator

I just tried to open one of the images and immediately checked /var/log/messages. Here's what appeared:

Those messages all appear to be from a system startup and are unrelated to anything you were doing with those files. Since you are not getting any "I/O Error" messages from processes trying to read the files, I wouldn't expect anything to be logged.

Operator · 07-22-2016, 04:47 PM

Quote:

Originally Posted by rknichols

It appears that you had copied/moved all those files into that "Phone Transfer" tree on Monday evening in preparation for copying them to your phone. Do you know if any of them were good after that (You said, "uhhhh... Monday or Tuesday...")? It's looking like not all of the buffered data got flushed to disk, but, if the transfer and power outage didn't occur until Tuesday, I don't know what would cause the dirty buffers to be held in memory for that long. You can look at the ctimes of the files on your Android phone to see just when you actually did the transfer and when it aborted due to the power failure ("ls -lctr | tail").

Your best bet at this point would be to shut that system down, copy an image of the entire partition or LVM volume to another disk (which you undoubtedly do not have right now), and then run photorec on that image to see what files can be recovered, perhaps from where they had been prior to moving them to this location. Anything you do with that system prior to making the image decreases the chances for a successful recovery, so shut it down now.

I actually do have that. I have that Passport HDD I mentioned before. I just have to learn how to do what you just said...

Quote:

Originally Posted by rknichols

Those messages all appear to be from a system startup and are unrelated to anything you were doing with those files. Since you are not getting any "I/O Error" messages from processes trying to read the files, I wouldn't expect anything to be logged.

Well I had opened /var/log/messages before I tried to open that picture and those entries were not there. I tried to open it and immediately opened messages again and those new entries had just been added.

Operator · 07-22-2016, 04:50 PM

Oh, so essentially you're suggesting putting the files back on the SD card from which they came? That is impossible - that card is bricked. After I was done removing the files and putting them on this computer, I formatted the disk, or attempted to, so my roommate could use it for her phone. The format failed and the card is toast. Just keeps getting better and better.

rknichols · 07-22-2016, 05:05 PM

Quote:

Originally Posted by Operator

I actually do have that. I have that Passport HDD I mentioned before. I just have to learn how to do what you just said...

It appears that the filesystem is in an LVM volume, /dev/mapper/{...something...}. You can use the df command to see what that "...something..." is. Then, the filesystem type on that Passport HDD is important. If it's some variety of FAT, the maximum file size is 4GB, so you can't store a full filesystem image as a file there. Got to take this one step at a time, as there are too many alternatives.

Quote:

Well I had opened /var/log/messages before I tried to open that picture and those entries were not there. I tried to open it and immediately opened messages again and those new entries had just been added.

Those messages are all from routine actions of systemd running in the background. They are mot related to anything you were doing at the time.

Operator · 07-22-2016, 05:07 PM

Not even the top two? Where it says Brightness and vignette_sharpness? Those are image properties

rknichols · 07-22-2016, 05:12 PM

Quote:

Originally Posted by Operator

Not even the top two? Where it says Brightness and vignette_sharpness? Those are image properties

Sorry, didn't notice those in the clutter. Still, all that might indicate is that the image file is corrupted. You already knew that from the "file" command reporting the file type as, "data". So, it's perhaps relevant, but still not meaningful.

Teufel · 07-22-2016, 05:21 PM

I'd try to use testdisk/photorec

Operator · 07-22-2016, 11:02 PM

I guess I just don't understand how a file corrupts.

rknichols · 07-23-2016, 06:19 AM

Quote:

Originally Posted by Operator

Oh, so essentially you're suggesting putting the files back on the SD card from which they came? That is impossible - that card is bricked. After I was done removing the files and putting them on this computer,...

Just saw that. So that's what you did on Monday evening. Do you know that the files were all good after transferring them to this computer? Somehow I doubt that you verified 27GB of files between Monday and Tuesday. It's looking like the files either weren't read properly from that bad SD card or the data blocks for some reason never got flushed out to disk on your computer. Neither of those scenarios gives any chance for recovery now. In my previous post I was hoping the files had been moved from some other directory on this computer and that there might be some hope of finding the old data blocks. Now I see that's not the case. I don't see much point in attempting forensic analysis of what's on your disk now. What you see now is what you've got.