Closed thezoggy closed 1 year ago
due to the
._*
resource forked version of the rar file
What do you mean with those words "resource forked"?
/Volumes/External 4/Completed/test_download_100MB.3/._sometestfile-100MB.part01.rar is not RAR archive
Do you understand where that file comes from? Does MacOS 13.1 introduce that, on exFAT? As copy / dummy? Why?
EDIT:
Ah, https://apple.stackexchange.com/questions/14980/why-are-dot-underscore-files-created-and-how-can-i-avoid-them/14981#14981 says "You can't avoid them (but see the dot_clean answer by Saeid Zebardast --they can be removed from a directory if that is what you need). They're created to store file information that would otherwise go into an extended attribute on HFS+ (Apple native) or Unix/UFS volumes; in earlier Mac OS this would be the resource fork."
The file downloaded from the nzb is sometestfile-100MB.part01.rar
but due to it being on external drive and not using a filesystem that prevents the need of the files when accessed mac created ._sometestfile-100MB.part01.rar
. This later rears its head as an invalid rar file and causes sab to fail.
for info about the ._ files: https://www.cnet.com/tech/computing/invisible-files-with-prefix-are-created-on-some-shared-volumes-and-external-disks/
You easily can see this type of issue if you were to insert usb drive with exfat on mac and copy files to it. Then take that drive to another machine you will prob see the extra metadata files that have no use to a non macos machine. We already deal with some of this by ignoring the .dsstore stuff this is just another thing that goes with that all.
macos 13 release notes they did mention:
There’s a change to the implementation of the msdos and exfat file systems. Apps that check for those specific file system formats might not detect them. Please file feedback if this impacts your app. (90768681)
but cant find exactly what that means..
And therefore you say "macos: ignore resource fork files", meaning "If on MacOS, do not add ._ files to the unrar command"? Because the problem occurs because the wildcard in "unrar *.rar" is ... too ... wild?
How about: On any OS, do not include files starting with . in the unrar? Because 1) easier and 2) starting with . means hidden, so fishy
And therefore you say "macos: ignore resource fork files", meaning "If on MacOS, do not add ._ files to the unrar command"? Because the problem occurs because the wildcard in "unrar *.rar" is ... too ... wild?
when we go to build list of what to extract we should avoid including them.
avoiding including ._*.rar
in list of stuff that needs extracting might be an easy thing to do for macos. there might be a smarter way to go about it.. i had thought we tried to detect if .rar had rar signature before we tried but maybe not?
so looks like file_is_rar is not used to add files to rarlist in build list.. so might could just use that.
but crudely we could also just pass on ._ files for macos at the start of the build_filelists https://github.com/sabnzbd/sabnzbd/blob/develop/sabnzbd/filesystem.py#L472 add:
if sabnzbd.MACOS and file.startswith("._"):
pass
Should probably fix it here? https://github.com/sabnzbd/sabnzbd/blob/e34301fb2fef9e5ab9d0a3fa70a2775babadc6c2/sabnzbd/filesystem.py#L762-L771
Should probably fix it here?
Oh? I would think here
https://github.com/sabnzbd/sabnzbd/blob/develop/sabnzbd/filesystem.py#L487-L489
and thus
https://github.com/sabnzbd/sabnzbd/blob/develop/sabnzbd/filesystem.py#L448
Or easier:
elif RAR_RE.search(file):
change to
elif RAR_RE.search(file) and not os.path.basename(file).startswith(".")
to exclude files starting "." on any OS.
>>> not os.path.basename("/bla/xxx/blabla123.rar").startswith(".")
True
>>> not os.path.basename("/bla/xxx/._blabla123.rar").startswith(".")
False
Now the reported problem is Rar, while this problem could occur in any files. What about par2 for example? Or zip? That's why it should be excluded at the source listing.
Ah, OK. And then maybe into IGNORED_FILES_AND_FOLDERS ?
sabnzbd/constants.py:128
IGNORED_FILES_AND_FOLDERS = ("@eaDir", ".appleDouble", ".DS_Store")
files that start with dot are valid and we shouldnt be tossing those out.
its just the ._
files when your on a mac you prob dont care about. (if were wanting to limit tossing out possibly valid stuff) but just doing it regardless of the os might not be too bad as someone easily could do something like have an external drive mounted on a mac but run sab on another os that happens to access that drive.. (quite suboptimal) but could happen.
but yes, as saf pointed out, thats prob the best place to do it. and its not a fixed name we can do as we need to look with starts with. just need to make sure were not preventing sab from cleaning stuff up after the fact because it gets excluded. havent had a chane to dig through to make sure of that.
just noticed github cut off a previous update,
here is the relevant drive from the output of: diskutil info -all
Device Identifier: disk7s2
Device Node: /dev/disk7s2
Whole: No
Part of Whole: disk7
Volume Name: External 4
Mounted: Yes
Mount Point: /Volumes/External 4
Partition Type: Microsoft Basic Data
File System Personality: ExFAT
Type (Bundle): exfat
Name (User Visible): ExFAT
OS Can Be Installed: No
Media Type: Generic
Protocol: USB
SMART Status: Not Supported
Volume UUID: F0EC9A2C-C013-<removed>
Disk / Partition UUID: 0BEC372C-C53E-<removed>
Partition Offset: 210763776 Bytes (411648 512-Byte-Device-Blocks)
Disk Size: 18.0 TB (17999996125184 Bytes) (exactly 35156242432 512-Byte-Units)
Device Block Size: 512 Bytes
Volume Total Space: 18.0 TB (17999694397440 Bytes) (exactly 35155653120 512-Byte-Units)
Volume Used Space: 1.1 TB (1086299045888 Bytes) (exactly 2121677824 512-Byte-Units) (6.0%)
Volume Free Space: 16.9 TB (16913395351552 Bytes) (exactly 33033975296 512-Byte-Units) (94.0%)
Allocation Block Size: 512 Bytes
Media OS Use Only: No
Media Read-Only: No
Volume Read-Only: No
Device Location: External
Removable Media: Fixed
Solid State: Info not available
I plugged in a usb thumb drive on my mac which has macOS 12.6.2. Formatted USB drive with exFAT and placed a .mkv file on it.
No ._ file from that action. But running "open x.mkv" on it, caused the file to open in mkv and resulted in ._x.mkv
being created.
Tried again with a .png and same thing. looking at the ._
file can see its a binary file and says its a resource fork within it.
Okay so I think I can replicate the user scenario, just need to get sab source and see if the fix I suggested works.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Should we just always ignore files starting with ._
, no matter what OS?
Since this could be a macOS disk mounted on Windows, etc..
We do the same for the other macOS specific filesystem tricks like .DS_store
.
I couldn't replicate this so far (sab download triggering the resource fork creation) on my Mac,. I can get them to generate by playing videos on external fat32/exfat drive.
I don't think it would hurt to just skip them generically
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
user on discord using 3.7.1 reported unrar failing on test download with "is not RAR archive" due to the
._*
resource forked version of the rar file being tried which of course is not an actual rar file:logs:
per user,
/Volumes/External 4
is an exFAT external drive. has been using this. issue started after macos 13.1 upgrade from last nightper https://developer.apple.com/documentation/macos-release-notes/macos-13-release-notes
trying to find out exactly what changed