Data Recovery – Fixing a 7z Archive That Can’t Be Read After Failed Move

archivecorruptiondata-recoverymv

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.

    Apr 29 23:14:28 frontear-net kernel: dolphin         D    0 567940      1 0x00004084
    Apr 29 23:14:28 frontear-net kernel: Call Trace:  ...
    
  • 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 be umount(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