Windows DrivePool imports fail during temporary-file movement

[DeusExTaco]

Component

Import / Collection Import; Docker / Deployment

Description

I received a separate Windows import report while reviewing #118. This appears to involve folder-import file operations on a Docker bind mount backed by StableBit DrivePool, rather than the native Windows download-client path mapping fixed by #119.

The reporter has approximately 20 local physical drives pooled into one Windows drive letter. A six-comic sample import produced repeated errors around temporary-file movement or replacement. One file eventually completed, while the others continued to fail after DrivePool balancing and antivirus interference were disabled.

This behavior has not yet been reproduced, and no diagnostic package or exact exception is available. It should not be treated as fixed by #119 without further evidence.

Reported environment

• Windows host
• Docker deployment
• Approximately 20 directly attached physical drives
• StableBit DrivePool presenting the drives as one local drive letter
• No NAS or network filesystem involved
• Pullbox source/library bind mounts backed by the pooled drive
• Pullbox version: unknown

Original user comments

Initial report from u/robotshavehearts2

Gave it a go. Still messing with it after getting it setup. I’ll admit I’m on windows and that makes docker stuff less than exciting. Feel like I always run into random things. I gave it a 6 comic sample to run through an import after setting it up and I got tossed a bunch of errors. None related to your app specifically. I believe they are errors because of how it is interface with my pooled drives potentially. I changed some settings in drivepool and adjust some virus settings, as I didn’t know if something else may be locking the file. I did get one to go through eventually, but the rest all got errors still. I’ll keep messing with it.

It does seem a bit slow to process etc, but that doesn’t bother me so much.

Other than that, my early feedback is that I like a lot of what it does. I’ll have to see how it works against real files, but seems okay so far. It’s a bit busy and has all lot of steps and data and info I feel like could all be culled. Personally, I just don’t care about most of it when I’m trying to manage my comics. I can overlook all of that though.

The matching system seemed to work well. I’ve tried a few that do the image matching for the cover which I always think works pretty well in combo with the other info. Wouldn’t mind seeing something like that here.

I’ll play with it more if I can get past this dumb docker stuff and maybe put together some real feedback and send you a message.

DrivePool follow-up from u/robotshavehearts2

Yeah, so I have like 20 drives hooked up to my PC. The c drive hosts windows and the rest of the drives are pooled into a single drive letter. But they are all local. None are networked or anything. It seems from troubleshooting that it has something to do with how the pathing works and the tmp file it needs being moved. Which is what made me wonder if something was locking it up, like the drivepool software balancing the drives or a virus scanner etc. but I had all of that off.

Would be great if a new version happened to fix it. Was not having fun troubleshooting it through the docker image. But I get windows stuff is a pain with that.

The broader interface and cover-matching feedback is retained above for provenance but is outside the scope of this bug.

Steps to reproduce

The precise configuration is not yet available. The reported flow was:

1. Run Pullbox in Docker on Windows.
2. Bind the import and/or library paths to a StableBit DrivePool drive.
3. Configure an import that performs file processing.
4. Import a six-comic sample.
5. Observe repeated failures involving temporary files being moved or replaced.
6. Disable DrivePool balancing and antivirus interference.
7. Retry and observe that most files still fail.

Expected behavior

Folder imports on a supported Windows Docker bind mount should complete without leaving partial artifacts. If the host filesystem temporarily locks a file, Pullbox should retry only errors known to be transient and then provide a clear, actionable failure if the operation remains blocked.

Actual behavior

One file eventually imported, but most files continued to fail during temporary-file movement or replacement. The exact exception, errno, paths, and import settings are not yet known.

Investigation requirements

• Obtain a Pullbox diagnostic package from the affected installation.
• Record the exact Pullbox version and Docker Desktop version.
• Record Compose volume mappings and DrivePool drive paths.
• Record import type and options: folder/Mylar, move/copy, conversion, rename, and ComicInfo update.
• Identify the failing operation: conversion staging, progress-state replacement, ComicInfo rewrite, library transfer, folder adoption, or rollback.
• Capture the exact exception and errno, especially EACCES, EBUSY, EPERM, EXDEV, or FileNotFoundError.
• Determine whether a bounded retry is appropriate without masking permanent permission or mapping errors.
• Add fault-injection tests before changing transfer behavior.

Acceptance criteria

• The failure is reproduced with DrivePool or a controlled equivalent filesystem-lock simulation.
• Transient Windows sharing violations are handled with a bounded, observable retry where safe.
• Permanent permission and path-mapping failures fail clearly.
• No source file, destination file, database record, or rollback record is left in an ambiguous partial state.
• Folder import behavior remains correct on ordinary Linux, macOS, Windows, NAS, and cross-device mounts.

Related issues

• SABnzbd Windows paths map to /downloads\..., causing false “dangerous files” rejection #118 tracks SABnzbd native Windows path normalization.
• fix: normalize Windows download paths #119 contains the proposed fix for SABnzbd Windows paths map to /downloads\..., causing false “dangerous files” rejection #118 and does not currently cover this import/DrivePool behavior.