Restore from lost+found
up vote
5
down vote
favorite
There was a problem on an EXT4 FS/memorycard and after and fsck all the files were put in the lost+found.
Question: how can I restore the old filename/hierarchy from the lost+found? Or it is impossible? Not counting a restore from backup.
data-recovery fsck lost-found
edited Jan 6 '15 at 22:47
Gilles
525k12610491578
add a comment |
up vote
5
down vote
favorite
There was a problem on an EXT4 FS/memorycard and after and fsck all the files were put in the lost+found.
Question: how can I restore the old filename/hierarchy from the lost+found? Or it is impossible? Not counting a restore from backup.
data-recovery fsck lost-found
edited Jan 6 '15 at 22:47
Gilles
525k12610491578
It won't restore the old hierarchy but if they are pictures, some photo organizer programs will read the EXIF data from the pictures and can import the files into a year/month/day hierarchy for you.
– drewbenn
Jan 6 '15 at 22:01
add a comment |
up vote
5
down vote
favorite
up vote
5
down vote
favorite
There was a problem on an EXT4 FS/memorycard and after and fsck all the files were put in the lost+found.
Question: how can I restore the old filename/hierarchy from the lost+found? Or it is impossible? Not counting a restore from backup.
data-recovery fsck lost-found
edited Jan 6 '15 at 22:47
Gilles
525k12610491578
There was a problem on an EXT4 FS/memorycard and after and fsck all the files were put in the lost+found.
Question: how can I restore the old filename/hierarchy from the lost+found? Or it is impossible? Not counting a restore from backup.
data-recovery fsck lost-found
data-recovery fsck lost-found
edited Jan 6 '15 at 22:47
Gilles
525k12610491578
edited Jan 6 '15 at 22:47
Gilles
525k12610491578
edited Jan 6 '15 at 22:47
Gilles
525k12610491578
edited Jan 6 '15 at 22:47
Gilles
525k12610491578
edited Jan 6 '15 at 22:47
Gilles
525k12610491578
525k12610491578
asked Jan 6 '15 at 8:09
user90825
It won't restore the old hierarchy but if they are pictures, some photo organizer programs will read the EXIF data from the pictures and can import the files into a year/month/day hierarchy for you.
– drewbenn
Jan 6 '15 at 22:01
add a comment |
It won't restore the old hierarchy but if they are pictures, some photo organizer programs will read the EXIF data from the pictures and can import the files into a year/month/day hierarchy for you.
– drewbenn
Jan 6 '15 at 22:01
It won't restore the old hierarchy but if they are pictures, some photo organizer programs will read the EXIF data from the pictures and can import the files into a year/month/day hierarchy for you.
– drewbenn
Jan 6 '15 at 22:01
It won't restore the old hierarchy but if they are pictures, some photo organizer programs will read the EXIF data from the pictures and can import the files into a year/month/day hierarchy for you.
– drewbenn
Jan 6 '15 at 22:01
add a comment |
5 Answers
5
active
oldest
votes
up vote
2
down vote
accepted
Last time I had to do that - many years ago - you had to guess based on file content. I doubt there is a better way today.
The 'file' program can help here since it will give you an idea of the type of data, so you can use this to view the files appropriately for a start.
answered Jan 6 '15 at 21:23
EricM
32113
add a comment |
up vote
4
down vote
You can't find the original name and location of a file in /lost+found because that's what lost+found is about: it's where fsck puts fragments of files that it hasn't been able to attach anywhere in the directory tree. If the location was known, fsck would have left the file where it was meant to be.
It's theoretically possible that fsck could have only partial information, such as the file name but not the directory location, but that doesn't happen with typical filesystem.
You may be able to find clues in the file itself. The file command will at least tell you what kind of file it is (if it recognizes it). Some files carry additional information inside; for example JPEG and TIFF images may contain EXIF data, MP3 files may contain ID3 tags, etc.
edited Apr 13 '17 at 12:36
Community♦
1
answered Jan 6 '15 at 23:55
Gilles
525k12610491578
add a comment |
up vote
0
down vote
The real answer is that you shouldn't try. You have no idea if the contents are complete. You should restore from a known good copy.
answered Jan 6 '15 at 21:57
bahamat
24.1k14690
add a comment |
up vote
0
down vote
File names and hierarchy no, but using file can help you recover some stuff. I use the Joe editor which has rectangular selections if you enable them. So I could do "ls > ques" then search-replace to turn it into a list of statements like 'file "#133024" > 133024.txt'. I ran that as an sh script, then I could do 'grep PDF *.txt > pdflist'. With that open in an mc viewer and another mc in another terminal I looked through pdflist.txt and moved all the PDFs into their own directory. You can do the same with ASCII text files and whatever else it identifies.
There are also the odd surprises like '#410423: gzip compressed data, was "x264_git.tar"'. You can also 'cat *.txt > filelist' to get the descriptions all in one file.
answered Jun 12 '17 at 3:20
Alan Corey
493
add a comment |
up vote
0
down vote
In my case there was I/O error during reading. And after run of e2fsck I've found most of my files in lost+found in subfolders, and most files (and filenames) was ok.
So go to lost+found, run
find | less
and see if you will find your files. Good luck!
answered Nov 30 at 8:56
1844144
1011
add a comment |
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
Last time I had to do that - many years ago - you had to guess based on file content. I doubt there is a better way today.
The 'file' program can help here since it will give you an idea of the type of data, so you can use this to view the files appropriately for a start.
answered Jan 6 '15 at 21:23
EricM
32113
add a comment |
up vote
2
down vote
accepted
Last time I had to do that - many years ago - you had to guess based on file content. I doubt there is a better way today.
The 'file' program can help here since it will give you an idea of the type of data, so you can use this to view the files appropriately for a start.
answered Jan 6 '15 at 21:23
EricM
32113
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
Last time I had to do that - many years ago - you had to guess based on file content. I doubt there is a better way today.
The 'file' program can help here since it will give you an idea of the type of data, so you can use this to view the files appropriately for a start.
answered Jan 6 '15 at 21:23
EricM
32113
Last time I had to do that - many years ago - you had to guess based on file content. I doubt there is a better way today.
The 'file' program can help here since it will give you an idea of the type of data, so you can use this to view the files appropriately for a start.
answered Jan 6 '15 at 21:23
EricM
32113
answered Jan 6 '15 at 21:23
EricM
32113
answered Jan 6 '15 at 21:23
EricM
32113
answered Jan 6 '15 at 21:23
EricM
32113
32113
add a comment |
add a comment |
up vote
4
down vote
You can't find the original name and location of a file in /lost+found because that's what lost+found is about: it's where fsck puts fragments of files that it hasn't been able to attach anywhere in the directory tree. If the location was known, fsck would have left the file where it was meant to be.
It's theoretically possible that fsck could have only partial information, such as the file name but not the directory location, but that doesn't happen with typical filesystem.
You may be able to find clues in the file itself. The file command will at least tell you what kind of file it is (if it recognizes it). Some files carry additional information inside; for example JPEG and TIFF images may contain EXIF data, MP3 files may contain ID3 tags, etc.
edited Apr 13 '17 at 12:36
Community♦
1
answered Jan 6 '15 at 23:55
Gilles
525k12610491578
add a comment |
up vote
4
down vote
You can't find the original name and location of a file in /lost+found because that's what lost+found is about: it's where fsck puts fragments of files that it hasn't been able to attach anywhere in the directory tree. If the location was known, fsck would have left the file where it was meant to be.
It's theoretically possible that fsck could have only partial information, such as the file name but not the directory location, but that doesn't happen with typical filesystem.
You may be able to find clues in the file itself. The file command will at least tell you what kind of file it is (if it recognizes it). Some files carry additional information inside; for example JPEG and TIFF images may contain EXIF data, MP3 files may contain ID3 tags, etc.
edited Apr 13 '17 at 12:36
Community♦
1
answered Jan 6 '15 at 23:55
Gilles
525k12610491578
add a comment |
up vote
4
down vote
up vote
4
down vote
You can't find the original name and location of a file in /lost+found because that's what lost+found is about: it's where fsck puts fragments of files that it hasn't been able to attach anywhere in the directory tree. If the location was known, fsck would have left the file where it was meant to be.
It's theoretically possible that fsck could have only partial information, such as the file name but not the directory location, but that doesn't happen with typical filesystem.
You may be able to find clues in the file itself. The file command will at least tell you what kind of file it is (if it recognizes it). Some files carry additional information inside; for example JPEG and TIFF images may contain EXIF data, MP3 files may contain ID3 tags, etc.
edited Apr 13 '17 at 12:36
Community♦
1
answered Jan 6 '15 at 23:55
Gilles
525k12610491578
You can't find the original name and location of a file in /lost+found because that's what lost+found is about: it's where fsck puts fragments of files that it hasn't been able to attach anywhere in the directory tree. If the location was known, fsck would have left the file where it was meant to be.
It's theoretically possible that fsck could have only partial information, such as the file name but not the directory location, but that doesn't happen with typical filesystem.
You may be able to find clues in the file itself. The file command will at least tell you what kind of file it is (if it recognizes it). Some files carry additional information inside; for example JPEG and TIFF images may contain EXIF data, MP3 files may contain ID3 tags, etc.
edited Apr 13 '17 at 12:36
Community♦
1
answered Jan 6 '15 at 23:55
Gilles
525k12610491578
edited Apr 13 '17 at 12:36
Community♦
1
edited Apr 13 '17 at 12:36
Community♦
1
edited Apr 13 '17 at 12:36
Community♦
1
1
answered Jan 6 '15 at 23:55
Gilles
525k12610491578
answered Jan 6 '15 at 23:55
Gilles
525k12610491578
answered Jan 6 '15 at 23:55
Gilles
525k12610491578
525k12610491578
add a comment |
add a comment |
up vote
0
down vote
The real answer is that you shouldn't try. You have no idea if the contents are complete. You should restore from a known good copy.
answered Jan 6 '15 at 21:57
bahamat
24.1k14690
add a comment |
up vote
0
down vote
The real answer is that you shouldn't try. You have no idea if the contents are complete. You should restore from a known good copy.
answered Jan 6 '15 at 21:57
bahamat
24.1k14690
add a comment |
up vote
0
down vote
up vote
0
down vote
The real answer is that you shouldn't try. You have no idea if the contents are complete. You should restore from a known good copy.
answered Jan 6 '15 at 21:57
bahamat
24.1k14690
The real answer is that you shouldn't try. You have no idea if the contents are complete. You should restore from a known good copy.
answered Jan 6 '15 at 21:57
bahamat
24.1k14690
answered Jan 6 '15 at 21:57
bahamat
24.1k14690
answered Jan 6 '15 at 21:57
bahamat
24.1k14690
answered Jan 6 '15 at 21:57
bahamat
24.1k14690
24.1k14690
add a comment |
add a comment |
up vote
0
down vote
File names and hierarchy no, but using file can help you recover some stuff. I use the Joe editor which has rectangular selections if you enable them. So I could do "ls > ques" then search-replace to turn it into a list of statements like 'file "#133024" > 133024.txt'. I ran that as an sh script, then I could do 'grep PDF *.txt > pdflist'. With that open in an mc viewer and another mc in another terminal I looked through pdflist.txt and moved all the PDFs into their own directory. You can do the same with ASCII text files and whatever else it identifies.
There are also the odd surprises like '#410423: gzip compressed data, was "x264_git.tar"'. You can also 'cat *.txt > filelist' to get the descriptions all in one file.
answered Jun 12 '17 at 3:20
Alan Corey
493
add a comment |
up vote
0
down vote
File names and hierarchy no, but using file can help you recover some stuff. I use the Joe editor which has rectangular selections if you enable them. So I could do "ls > ques" then search-replace to turn it into a list of statements like 'file "#133024" > 133024.txt'. I ran that as an sh script, then I could do 'grep PDF *.txt > pdflist'. With that open in an mc viewer and another mc in another terminal I looked through pdflist.txt and moved all the PDFs into their own directory. You can do the same with ASCII text files and whatever else it identifies.
There are also the odd surprises like '#410423: gzip compressed data, was "x264_git.tar"'. You can also 'cat *.txt > filelist' to get the descriptions all in one file.
answered Jun 12 '17 at 3:20
Alan Corey
493
add a comment |
up vote
0
down vote
up vote
0
down vote
File names and hierarchy no, but using file can help you recover some stuff. I use the Joe editor which has rectangular selections if you enable them. So I could do "ls > ques" then search-replace to turn it into a list of statements like 'file "#133024" > 133024.txt'. I ran that as an sh script, then I could do 'grep PDF *.txt > pdflist'. With that open in an mc viewer and another mc in another terminal I looked through pdflist.txt and moved all the PDFs into their own directory. You can do the same with ASCII text files and whatever else it identifies.
There are also the odd surprises like '#410423: gzip compressed data, was "x264_git.tar"'. You can also 'cat *.txt > filelist' to get the descriptions all in one file.
answered Jun 12 '17 at 3:20
Alan Corey
493
File names and hierarchy no, but using file can help you recover some stuff. I use the Joe editor which has rectangular selections if you enable them. So I could do "ls > ques" then search-replace to turn it into a list of statements like 'file "#133024" > 133024.txt'. I ran that as an sh script, then I could do 'grep PDF *.txt > pdflist'. With that open in an mc viewer and another mc in another terminal I looked through pdflist.txt and moved all the PDFs into their own directory. You can do the same with ASCII text files and whatever else it identifies.
There are also the odd surprises like '#410423: gzip compressed data, was "x264_git.tar"'. You can also 'cat *.txt > filelist' to get the descriptions all in one file.
answered Jun 12 '17 at 3:20
Alan Corey
493
answered Jun 12 '17 at 3:20
Alan Corey
493
answered Jun 12 '17 at 3:20
Alan Corey
493
answered Jun 12 '17 at 3:20
Alan Corey
493
493
add a comment |
add a comment |
up vote
0
down vote
In my case there was I/O error during reading. And after run of e2fsck I've found most of my files in lost+found in subfolders, and most files (and filenames) was ok.
So go to lost+found, run
find | less
and see if you will find your files. Good luck!
answered Nov 30 at 8:56
1844144
1011
add a comment |
up vote
0
down vote
In my case there was I/O error during reading. And after run of e2fsck I've found most of my files in lost+found in subfolders, and most files (and filenames) was ok.
So go to lost+found, run
find | less
and see if you will find your files. Good luck!
answered Nov 30 at 8:56
1844144
1011
add a comment |
up vote
0
down vote
up vote
0
down vote
In my case there was I/O error during reading. And after run of e2fsck I've found most of my files in lost+found in subfolders, and most files (and filenames) was ok.
So go to lost+found, run
find | less
and see if you will find your files. Good luck!
answered Nov 30 at 8:56
1844144
1011
In my case there was I/O error during reading. And after run of e2fsck I've found most of my files in lost+found in subfolders, and most files (and filenames) was ok.
So go to lost+found, run
find | less
and see if you will find your files. Good luck!
answered Nov 30 at 8:56
1844144
1011
answered Nov 30 at 8:56
1844144
1011
answered Nov 30 at 8:56
1844144
1011
answered Nov 30 at 8:56
1844144
1011
1011
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f177691%2frestore-from-lostfound%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It won't restore the old hierarchy but if they are pictures, some photo organizer programs will read the EXIF data from the pictures and can import the files into a year/month/day hierarchy for you.
– drewbenn
Jan 6 '15 at 22:01