(Resolved) Attachments 404 after successfully downloading from WebDAV on iOS

edited September 28, 2022
Hello! Firstly, thank you for all of the hard work on this app, I really love it.

I’m using both the iPad, iPhone, and Linux apps in concert and am running into an issue with WebDAV attachment syncing. A given item is either successfully or unsuccessfully accessible, but many attachments fail to download with only a few ever succeeding.

Logs have been sent at D1914122861.

On my desktop, I can attach a PDF to an item, see it on the WebDAV, open the file from the local cache, all using the same file ID. That works as expected. When I try to download that attachment from either iOS device in the Zotero app, it successfully downloads the file, but ultimately displays an error message that the item cannot be found. I know that the item was successfully downloaded, however; I can see in my WebDAV logs that its clients requested a file by the correct ID and that it was successfully transmitted to that client, and within the Zotero cache, I can see that the used cache storage increases by the exact amount of the ZIP file’s size. So there should be no auth or download issues. My assumption (not that you need my theories!) is that the app has a mismatch of expectations about how to locate the file inside of the ZIP file where the desktop app has expectations consistent with what it finds there.

If there’s anything else I can do to help resolve the issue, please let me know. I can provide anything from screenshots to logs to detailed network traffic recording if necessary. Thank you!
  • If you unzip 2AIE24JQ.zip from the WebDAV server, what do you see inside it? Zotero is expecting a single file — literally named "file" — within it. This is the case for two files in your library, both created a week ago. Do you recall how you added those items and files?

    (As for the difference between desktop and iOS, the desktop app will use a single file within a ZIP even if it doesn't match the expected filename for some reason. I don't think the iOS app does that yet.)
  • edited September 28, 2022
    Actually it looks like iOS does follow that same behavior, but it wouldn't currently work if the expected file (here "file") doesn't have an extension. So maybe there's a PDF in the ZIP but somehow the expected filename is set to "file"? We can probably improve this, but knowing how you saved the file would be helpful to figure out how you ended up with "file".
  • Eeehhhh yeah, that ZIP file is as you describe, with that file having been renamed without an extension. That's set up that way from how I was testing this misbehavior, though the missing extension was not an intended part of the test. Let me record a different item expressing the same behavior with a less broken-looking file. Generally, I'm printing a PDF of an item and drag-dropping it into the Linux desktop UI. The resulting filename tends to be mildly long with spaces in it, so in this case I was trying to test it with a filename with no spaces.

    *tries to find a valid case to test and log*

    Okay, well that's awful. Turns out the browser extension I was using to capture PDFs _was not putting the file extension into the filename_. I never noticed because the metadata was there to indicate it was a PDF so everything worked fine desktop-side. When I correct for this, everything works as expected. And now I have a whole bunch of attachments I have to go correct, oi. Thank you for your assistance!
  • Well, the problem of iOS not handling a misnamed file the same way without an extension is something we can fix, if you can wait.
  • That sounds valuable too, but I ought to fix up my attachments regardless because those extensionless files probably wouldn't make sense to the rest of iOS should I, say, download the attachment into device storage. I wouldn't say that it's a reasonable expectation that an app handles extensionless files correctly, it's a bit of an odd case so it wouldn't hurt my feelings if that particular fix ranked very low in your priorities.
  • Thanks for reporting @shainehatch. I've fixed the issue and it'll be available in next beta build. If you don't want to rename all your attachments you can use beta for a while.
  • I've installed the beta and confirmed it's working as expected. Thank you for the quick turnaround!
Sign In or Register to comment.