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.