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

I was transferring files from my computer (Fedora Linux 22) to my Android phone and the power went out. I can see all the files in the folder on the computer and some on the phone as well, with their names and subdirectories, but I can't open any of them, and I have no idea where to start. It was about 27GiB. I wouldn't think every single one of them would suddenly be corrupted due to the transfer interruption, but that appears to be so. What do?

so... am I screwed?

it may just be a permission problem, what does the stat command give for the files/folder on the computer?

That's for the folder they're in, not the folders themselves... here's a subfolder.

What's interesting is the files that made it to the phone display with no problem. The files that remained on the computer are all inaccessible, even when I move them to the phone now.

Have never seen this:So could be a problem, can you copy a file out of the damaged folder ( maybe as root ) and open it from a new location?

Wasn't fsck utility invented to fix problems like this?

Yes, I can interact with the files just like they aren't damaged. I copied them to the phone anyway (some of them) to see if that would do anything and no go. I'll have to try copying as root when I get home...
That's what I thought, but fsck didn't seem to do much... maybe I used it incorrectly?

What output did you get from fsck?

Man, right now I don't even recall... got sick at work yesterday and left early, don't remember much about when I was home. I can run it again tonight and give you output if that'd be okay.

What's also interesting is the output of 'file' on any of the images just lists it as 'data.' As though they're encrypted... but if they were encrypted, how come moving them to the phone worked fine until the outage, but now none of them are good?

Sounds like they are fubar'ed, if you have backups it might just be easier to restore from them.

I don't. This was supposed to BE the backup. But why would this all just... stop... I would think maybe the file that was in the process of being transferred would be effed, not the ENTIRE FOLDER.

The power outage has probably corrupted the underlying filesystem.
Have a look here:
https://docs.fedoraproject.org/en-US...ing_Files.html

Looks like this could be your problem, might have helped if you had said you was on SELinux.

Baby steps. I'm a Ford truck mechanic, and I "know more than the vast majority" of people with computers, but not all... clearly not what needs to be mentioned apparently.

At any rate thank you for the link :) I'll definitely be checking that out when I get home

Don't get humpy with me pal I'm trying to help, this info would have been helpful, and being reminded politly to include extra info on your problem is a reasonable request, so I am outta here if you want to give me attitude about helping you to help us with your problem!

Uh... that wasn't attitude... that was just humor and a sheepish apology for not providing enough information...

Now can we continue talking like gentlemen or... no?

That "unconfined_u:object_r:user_home_t:s0" is a perfectly normal SELinux context for files under your home directory. No problem there.

What application or command were you using to do the transfer? That might help in understanding what happened. Unless you told it to move the files or delete the source files after the transfer (unlikely -- you said this was intended as a backup), the source files should not have been affected.

Running fsck in these situations (except in it's automatic "preen" (-p) mode) is not a good idea. The job of fsck is to make the filesystem consistent, and that can sometimes come at the expense of user data.

Hmm, okay...

I'm just using F22 with Gnome. I had the MicroSD card in my phone, phone plugged in via USB to the laptop, pulled both folders - the local computer folder and the SD card - up side by side, selected the files on the computer, and tried to drag the selection over to the SD card.

I did give my unskilled hand a shot at running fsck after this all happened, BUT before that (just to prevent further damage, I guess) I copied the folder to an external HD. I'm pretty sure I did run fsck with -p on the folder on the computer but the folder on the external HD is as it was immediately after the outage with no further changes.

I was under the impression that a click and drag to external storage would end up as a copy, not a cut... maybe I'm wrong

Yes, the default should be "copy" when the source and destinations are on different filesystems. There would be a little "+" sign with the "hand" cursor to indicate a copy. Holding down the shift key changes the operation to "move", and the "+" sign changes to a little arrow. When going between directories on the same filesystem, the default is "move" and you have to hold down the ctrl key to copy.

Is the source filesystem ext4? I've lost track of what Fedora uses as a default filesystem.

Man, I'm not even sure. I'm sorry guys. I'll have to get you more when I get home. That'll be pretty soon here after I get my daughter from day care (and get off work in a half hour).

Okay. I'm back and using the computer in question. Quick way to check the file system type of it, please?

Mount ought to tell you the filesystem of any mounted drive:

For what it's worth, xfs is the default FS for Red Hat so I think that's probably what it is for Fedora as well. Could be ext4, I reckon.

Otherwise, parted can definitely tell you the FS for both a mounted and unmounted drive:

Also, "df -T" will report the filesystem type as well as the space.

Okay... let's go with df. mount is a lot to read. Okay, the folder in question is in the /home partition (of course, right?). df says /home is ext4. Do you also need that of the phone?

No, the filesystem on the phone shouldn't matter. For some of the corrupted files, what is the inode change time shown by "ls -lc"? Just for comparison, look at that for a few of the non-corrupted files as well. Also, how recently were the corrupted files known to be good?

I'll check the ls -lc results when I get home again. The non-corrupted files were good as of uhhhh... Monday or Tuesday... Monday is when Amazon dropped off my replacement memory card but IIRC I didn't start the file transfer until Tuesday night.

Okay, here are the ls -lc results for the parent directories
and here's ls -lc | tail inside the Music folder, all unavailable to open

I like: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!

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.

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

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.

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.

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...
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.

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.

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.

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.

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.

I'd try to use testdisk/photorec

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

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.