Closed KyleSanderson closed 7 years ago
Thanks for the enhancement suggestion. I will classify this as an enhancement since I do not believe bailing on corrupt/incomplete archives really is not the right thing to do. Blindly returning data that does not exist may or may not work depending on what data the archive is carrying and how it is expected to be returned. You mentioned media playback in issue #50, but if the first volume file does not exist, the chance of it working is very slim since the file magic is not available. Returning dummy data at reads from archives that does not otherwise exist or return whatever corrupt information is there is doable and I will consider it and track the progress in this thread.
But considering the very limited time I have to spend on this project I need to prioritize the more serious issues/bugs reported and less narrow use cases. Currently that would be issue #49. Sorry for any inconvenience this may cause you.
To allow reading from incomplete and/or corrupt archives in store mode should be fairly easy. The first two volumes files must exist however since they contain key information to be able to properly calculate file offsets. If data cannot be accessed due to a missing file the read request(s) can return all 0. If that works or not is more about how the client will react on such data being returned. For compressed archives it is more tricky since extraction is mainly performed in libunrar and it will expect files to be present. I am not really sure that programs like rarfilesource
can even coop with compressed archives?
I wouldn't worry about compression, for media and ilk rar is just used for file splitting.
rar2fs does not really care what you chose to shove into those RARs. Simply saying that store mode is easy to handle, any level of compression is not. The thing that makes rar2fs differ from many other tools is that it handles also compressed archives (with some limitations). Many media files comes with compression as default, such as vobsub and cba.
Sorry for the confusion. The typical usage today with RARs is not to compress contents, but simply to split a single compressed file, like a .mkv, across multiple archives. This is because zip doesn't sanely support archive splitting and there are no reasonable tools to manipulate/maintain them. RAR is used as a storage container mostly, in store mode as you indicated.
Does this make a little more sense? :-)
I do not think you need to explain yourself. I know very well how this works. But rar2fs is a RAR file system. It is not written for a specific archive contents. How it is used on the other hand is user discretion.
I will add support for simply ignoring read errors in store mode. If that needs an options to enable/disable I have not yet decided. Hopefully this will improve things somewhat according to your request.
EDIT: Note that what we are talking about here is extraction. Listing of archives can never accept read errors and still needs to abort, hopefully not before all files have been located. Without proper headers some files might not be possible to identify.
EDIT2: Actually, listing works just fine as is :) What will happen if a file is missing or corrupt is that it will be ignored or show up as a regular file, but scanning of headers will continue until the end or whenever --seek-length
tells it to stop.
Try this patch on master/HEAD for a corrupt/incomplete archive, it should allow extraction even if files are missing but with bogus data. Handling of short byte counts due to a possible trunction or other low level access errors are not covered yet.
Thanks man, I'll try the patch when time permits (I have a bunch of travel coming up/on-going).
Patch covering also low level access errors.
(patch v2 was broken and has been removed) raw_read_v3.txt
Note that this patch applies clean only on 55a8c81e0da9827c21cd1bc2ad4326b5e5351dd8
New patch rebased on master raw_read_v4.txt
Since I am not getting any feedback on the patch I will consider this issue as resolved. Case closed.
At the moment alternatives like rarfilesource happily continue along if any parts of an archive are missing (beginning, middle, and end). It doesn't matter if the archives are corrupt either, alternatives to rar2fs continue along.
Continuing this from issue 50, it would be awesome if rar2fs had this functionality.