LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   File transfer stopped, now can't open any of the files (https://www.linuxquestions.org/questions/linux-software-2/file-transfer-stopped-now-cant-open-any-of-the-files-4175585149/)

Operator 07-20-2016 02:32 PM

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?

Operator 07-20-2016 06:05 PM

so... am I screwed?

Keith Hedger 07-20-2016 06:40 PM

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

Operator 07-20-2016 06:51 PM

Code:

  File: ‘/home/username/Documents/Phone transfer’
  Size: 4096              Blocks: 8          IO Block: 4096  directory
Device: fd02h/64770d        Inode: 6029888    Links: 15
Access: (0755/drwxr-xr-x)  Uid: ( 1001/username)  Gid: ( 1001/username)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2016-07-20 13:49:32.282842348 -0400
Modify: 2016-07-18 18:21:02.768617319 -0400
Change: 2016-07-18 18:21:02.768617319 -0400
 Birth: -

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

Code:

  File: ‘/home/username/Documents/Phone transfer/Music/’
  Size: 12288            Blocks: 24        IO Block: 4096  directory
Device: fd02h/64770d        Inode: 7078190    Links: 58
Access: (0755/drwxr-xr-x)  Uid: ( 1001/username)  Gid: ( 1001/username)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2016-07-20 13:49:35.434665539 -0400
Modify: 2016-07-18 18:04:21.000000000 -0400
Change: 2016-07-18 18:04:21.771726342 -0400
 Birth: -


Operator 07-20-2016 06:54 PM

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.

Keith Hedger 07-21-2016 05:28 AM

Have never seen this:
Code:

... Context: unconfined_u:object_r:user_home_t:s0 ...
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?

Emerson 07-21-2016 06:54 AM

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

Operator 07-21-2016 07:54 AM

Quote:

Originally Posted by Keith Hedger (Post 5579248)
Have never seen this:
Code:

... Context: unconfined_u:object_r:user_home_t:s0 ...
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?

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

Originally Posted by Emerson (Post 5579267)
Wasn't fsck utility invented to fix problems like this?

That's what I thought, but fsck didn't seem to do much... maybe I used it incorrectly?

Emerson 07-21-2016 07:55 AM

What output did you get from fsck?

Operator 07-21-2016 07:56 AM

Quote:

Originally Posted by Emerson (Post 5579299)
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.

Operator 07-21-2016 08:27 AM

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?

Keith Hedger 07-21-2016 09:58 AM

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

Operator 07-21-2016 10:06 AM

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.

Keith Hedger 07-21-2016 10:35 AM

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.

Operator 07-21-2016 10:40 AM

Quote:

Originally Posted by Keith Hedger (Post 5579368)
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.

Operator 07-21-2016 10:40 AM

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

Keith Hedger 07-21-2016 10:44 AM

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!

Operator 07-21-2016 10:45 AM

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

Operator 07-21-2016 10:57 AM

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

rknichols 07-21-2016 11:30 AM

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.

Operator 07-21-2016 11:34 AM

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.

Operator 07-21-2016 11:34 AM

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

rknichols 07-21-2016 01:20 PM

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.

Operator 07-21-2016 01:24 PM

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

Operator 07-21-2016 04:48 PM

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

notKlaatu 07-21-2016 04:50 PM

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

Code:

mount
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:

Code:

$ sudo parted /dev/sdc print

rknichols 07-21-2016 05:02 PM

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

Operator 07-21-2016 05:23 PM

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?

rknichols 07-21-2016 07:27 PM

Quote:

Originally Posted by Operator (Post 5579566)
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?

Operator 07-22-2016 06:46 AM

Quote:

Originally Posted by rknichols (Post 5579597)
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.

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 (Post 5580008)
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 (Post 5580018)
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 (Post 5580021)
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 (Post 5580023)
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 (Post 5580028)
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 (Post 5580040)
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 (Post 5580031)
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.


All times are GMT -5. The time now is 01:02 AM.