Closed Tiefkuehlpizze closed 4 years ago
I also get many errors like:
2020/06/20 - 16:20:17: cp: /storage/emulated/0/OAndBackupX/pl.solidexplorer2/pl.solidexplorer2/lib: Operation not permitted [SolidExplorer]
Is my backup complete nevertheless?
@PiQuer it's mostly complete. Even if you get a notification that says otherwise. This problem has to do with apps with special folders.
I'm not sure at the moment. But it seems, that the compression function has issues. Maybe the strategy needs to be changed.
I cannot tell, if the backups are useless. It might be corrupt, but there is also a good chance, that it's a false or unproblematic error or the app can recover itself.
But it's better find a good solution. I don't like error messages on my backups.
Antother update. I've fixed issues with the F-Droid installation on my device.
It's a bit weird. If I just backup F-Droid or my last backup in batch mode is F-Droid, it was throwing these errors now:
2020/06/21 - 23:45:30: cp: /data/user/0/org.fdroid.fdroid/files/fdroid/repo/org.fdroid.fdroid_1000011.apk: No such file or directory [F-Droid]
I've checked it via shell and yes: It was following dead symlinks. I guess an old version of F-Droid created these or they came because I'm carrying my Titanium Backup'ed version for ages.
Anyway, I have another issue with a similar nature:
2020/06/21 - 16:58:03: cp: /storage/emulated/0/OAndBackupX/cz.zdenekhorak.mibandtools/cz.zdenekhorak.mibandtools/files/default.realm.management/access_control.new_commit.cv: Invalid argument [Mi Band Tools]
2020/06/21 - 16:58:03: cp: /storage/emulated/0/OAndBackupX/cz.zdenekhorak.mibandtools/cz.zdenekhorak.mibandtools/files/default.realm.note: Invalid argument [Mi Band Tools]```
These files are pipes and here we run into a big problem:
% ls -l
total 4
-rw------- 1 pizze users 0 Jun 12 10:22 access_control.control.mx
-rw------- 1 pizze users 0 Jun 12 10:22 access_control.write.mx
prw------- 1 pizze users 0 Apr 11 21:49 access_control.new_commit.cv
prw------- 1 pizze users 0 Apr 11 21:49 access_control.pick_writer.cv
% zip test.zip *
zip warning: ignoring FIFO (Named Pipe) - use -FI to read: access_control.new_commit.cv
zip warning: ignoring FIFO (Named Pipe) - use -FI to read: access_control.pick_writer.cv
updating: access_control.control.mx (stored 0%)
updating: access_control.write.mx (stored 0%)
% tar czvf test.tar.gz *
access_control.control.mx
access_control.new_commit.cv
access_control.pick_writer.cv
access_control.write.mx
test.zip
% tar -tvf test.tar.gz
-rw------- pizze/users 0 2020-06-12 10:22 access_control.control.mx
prw------- pizze/users 0 2020-04-11 21:49 access_control.new_commit.cv
prw------- pizze/users 0 2020-04-11 21:49 access_control.pick_writer.cv
-rw------- pizze/users 0 2020-06-12 10:22 access_control.write.mx
-rw-r--r-- pizze/users 374 2020-06-22 00:02 test.zip
zip does not support pipes while tar does. My suggestion here is pretty obvious. :)
I've errors when backup some apps:
BackupFailedException: cp: /storage/emulated/0/OABX/it.wind.myWind/data/files/eime.realm.enc.note: Invalid argument
BackupFailedException: cp: /storage/emulated/0/OABX/im.vector.app/data/files/matrix-sdk-auth.realm.management/access_control.new_commit.cv: Invalid argument
BackupFailedException: cp: /storage/emulated/0/OABX/com.xda.labs/data/files/.realm.temp/5716813994014153188_realm.note: Invalid argument
@darhma please check #84
@machiav3lli Thank you, I've checked #84 and I've solved by deleting their respective folders in OABX's backup folder. I've "verify apps over usb" in developer settings turned off.
Update: the problem isn't solved the backup of the apps doesn't work. When I try to restore the backup isn't there. It says that the last backup is from 1 january 1970 01:00:00. In the folder there is only an apk file, no data.
I also noticed that the app does not create the copy of the oandbackupx apk in the OABX folder
I know you guys are looking for a solution for symlinks and named pipes. In the meanwhile, is it possible to include the ability to manually exclude a file from backup as a temporary workaround?
BTW, isn't #84 a duplicate of this one?
It's not possible to detect and exclude symlinks that easy, since we only have the toybox tools running as root. This means, we would need to parse output from ls and let the logic which is currently simply a call to toybox cp -R
react on symlinks. I'm building something like that, but it'll need some more time.
I did read your comments on the other issue, so I'm aware it isn't easy. But what about manual exclusion?
Can you describe it a bit more? The user is able to delete symlinks from the data directories with a root shell or file explorer. It could be done with a shell script using find. I'm not sure about the effects, but at least it would destroy the data in the same way, as it would happen when symlinks are simply ignored and then a backup is restored. :)
Ah. Well, I didn't think to try that angle...
Then I have no problem. I can use that instead. Sorry!
Hmmm. Even with root, I can't copy either symlinks or named pipes. So I can't even back them up in case something goes wrong.
The backup strategy is, to copy everything to the backup folder and compress it then. Since the storage is sdcardfs (FAT32 or so), it does not support symlinks or pipes.
I don't mean the app. I mean using a root file explorer, I still can't copy a symlink or named pipe. Or are you saying they can only be deleted using root, but not copied?
It has to do with the fact that storage file system is for most devices sdcardfs which basically doesn't support following symlinks for standard operations.
I see. Thanks!
Hmmm. Even with root, I can't copy either symlinks or named pipes. So I can't even back them up in case something goes wrong.
UPDATE. Apparently, I can copy the symlink if I stay in root storage. I just can't copy it to the non-root internal storage. So I'm going to make a random folder in /data/data and put the whole Fenix profile backup there and then try to update it. Hopefully, nothing breaks, but if it does, at least I can manually paste back my profile. Wish me luck!
Edit: Well, I didn't need to restore the backup, but for now, my procedure is: cut and paste lock file outside Fenix data folder -> backup the app and data -> paste the lock file back where it was -> update Fenix.
I also tried to copy a Named Pipe, but that process is either endless or gets stuck.
So I'm going to make a random folder in /data/data and put the whole Fenix profile backup there and then try to update it. Hopefully, nothing breaks, but if it does, at least I can manually paste back my profile. Wish me luck!
As long as you don't wipe the data partition, you're going to find it there again. This can also be a backup strategy, but you have to keep in mind, that also the system data remains. Updating like this is called "dirty flash" because you're not wiping your data to have a clean system.
@Tiefkuehlpizze I don't "dirty flash". When I have to restore an app backup, I delete the app completely. Since this is Fenix, and we know backups are currently a problem, I will also check if the org.mozilla.fenix folder is gone from /data/data or not. Only then will I restore the backup. Since the lock file I'm keeping separately from the backup is the same "version" as the backup itself, it shouldn't cause any issues, in theory.
The mentioned errors occur on symlinks and special files like named pipes: