I was trying to move my old 7z archive from an older ext4 partition to my current one, but in the process it randomly seems to have cancelled. Not only does the new location possess an incomplete archive, which cant be read, but the old location has a 7z.part
file. Is it possible to somehow continue the moving process? I can't seem to figure it out simply from the file explorer's UI, but I was wondering if there might be a terminal command?
Using ls
in the old directory shows the old 7z file, but its name seems to be red, and ls claims it cannot be read (I/O error). Using it in the new directory seems to also show it as red, but it doesn't have the same error
The old directory was ~/Documents/Archive/backup (on a different partition, as this was from an older installation of Linux)
[frontear@frontear-net backup]$ ls
ls: cannot access 'OneDrive.7z': Input/output error
OneDrive.7z OneDrive.7z.part
Although ls
claims a OneDrive.7z exists here, it's actually not visible via the file explorer, even with hidden files enabled
The current directory is ~/Desktop/Archive/backup (my current Linux install)
[frontear@frontear-net backup]$ ls
OneDrive.7z
In both commands, the OneDrive.7z is in a red color, which I take to mean something, probably in regards to it being corrupted
Running fsck
from a Manjaro Live ISO yields no obvious signs of corruption. /dev/sda2
is my current partition, whereas /dev/sda3
is the old partition.
[manjaro manjaro]$ sudo fsck /dev/sda2
fsck from util-linux 2.34
e2fsck 1.45.4 (23-Sep-2019)
/dev/sda2: clean, 738853/39223296 files, 76011466/156883968 blocks
[manjaro manjaro]# fsck /dev/sda3
fsck from util-linux 2.34
e2fsck 1.45.4 (23-Sep-2019)
Superblock last write time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set)
/dev/sda3: clean, 4362438/9715712 files, 18432430/38835968 blocks
Edit: Updated fsck
at the request of Timothy Baldwin:
[manjaro manjaro]# fsck -f /dev/sda2
fsck from util-linux 2.34
e2fsck 1.45.4 (23-Sep-2019)
Pass 1: Checking inodes, blocks, and sizes
Inode 19400943 extent tree (at level 2) could be narrower. Optimize<y>? yes
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 757397/39223296 files (0.5% non-contiguous), 80084462/156883968 blocks
[manjaro manjaro]# fsck -f /dev/sda3
fsck from util-linux 2.34
e2fsck 1.45.4 (23-Sep-2019)
Superblock last mount time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set)
Superblock last write time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda3: 4362438/9715712 files (0.1% non-contiguous), 18432430/38835968 blocks
Edit 2: Updated ls
to ls -l
:
[frontear@frontear-net ~]$ cd ~/Documents/Archive/backup/
[frontear@frontear-net backup]$ ls -l
ls: cannot access 'OneDrive.7z': Input/output error
total 2168832
-????????? ? ? ? ? ? OneDrive.7z
-rw------- 1 frontear frontear 2220883968 Apr 30 06:46 OneDrive.7z.part
[frontear@frontear-net backup]$ cd ~/Desktop/Archive/backup/
[frontear@frontear-net backup]$ ls -l
total 2446952
-rw------- 1 frontear frontear 2220883968 Apr 29 23:13 OneDrive.7z
Edit 3: Added a smartctl
check:
[manjaro@manjaro ~]$ sudo smartctl -a /dev/sda | sed -n '/Threshold/,/^$/p'
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0
2 Throughput_Performance 0x0004 142 142 000 Old_age Offline - 70
3 Spin_Up_Time 0x0007 128 128 024 Pre-fail Always - 177 (Average 180)
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 2450
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000a 100 100 000 Old_age Always - 0
8 Seek_Time_Performance 0x0004 118 118 000 Old_age Offline - 33
9 Power_On_Hours 0x0012 097 097 000 Old_age Always - 23216
10 Spin_Retry_Count 0x0012 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 2388
192 Power-Off_Retract_Count 0x0032 098 098 000 Old_age Always - 2461
193 Load_Cycle_Count 0x0012 098 098 000 Old_age Always - 2461
194 Temperature_Celsius 0x0002 119 119 000 Old_age Always - 46 (Min/Max 20/53)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
240 Head_Flying_Hours 0x0012 097 097 000 Old_age Always - 23203
241 Total_LBAs_Written 0x0012 100 100 000 Old_age Always - 171426971200
242 Total_LBAs_Read 0x0012 100 100 000 Old_age Always - 228792438899
Edit 4: badblocks
check
[manjaro@manjaro ~]$ sudo badblocks -sv /dev/sda
Checking blocks 0 to 976762583
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found. (0/0/0 errors)
Best Answer
I think I have a hunch what had happened (based on your dmesg).
What happened during your move is that your Dolphin has crashed during the moving process.
You have used some filesystem that needed FUSE like NTFS, etc. Which probably caused a deadlock (a wild guess a cache overflow or similar)
If the original is damaged than it is a serious bug in Dolphin, FUSE, or the NTFS-3g driver you are probably using.
Now to your original question
Out of curiosity could you execute:
sudo chmod -R g+x ~/Documents/Archive/backup
? I wonder what will happen.It appears that the file you are trying to list is damaged, that is the reason why you are getting the error :
ls: cannot access 'OneDrive.7z': Input/output error
. (from the actions you have taken it appears that the your HW is OK). Your file system (journal?) appears to be damaged. Before attempting fixing it I would highly recommend creating a disk image via e.g. ddrescue.(Note: When doing a
fsck
don't forget that the filesystem must beumount
(ed)!)The answer your question, if the copy process can be continued?
It can't because you are using the wrong tool for the task.
You should be using rsync or similar tool to make sure you have correct copy of the original file.
How to recover your bad 7z file?
The best bet is to follow these instructions - How to recover corrupted 7z archive from 7-zip.org.
What to do better next time?
1) Use rsync for copying, moving, etc important files
2) Split large files into more smaller files
3) When compressing use a recovery information - 7zip does not support adding the recovery information, but it can be added in a par1.0/par2.0 format. (for linux use par2cmdline or gui Easy Par2 for KDE, for windows you can use MultiPar or MultiPar on Github; QuickPar).
4) For storage use advanced filesystems like zfs (with ECC RAM) to improve your data integrity