Give every job a staging path of its own

`<cacheDir>/conversions/` is shared by the convert tab, the join tab and `ConcatEngine`, and
until now none of the three named a file that belonged to one job. A conversion derived its name
from the input's display name, so two `holiday.mp4` from different folders wrote the same file.
A join used the constant `joined.<ext>`, so any two joins of one format did. The list file was
the constant `concat_list.txt`, so any two joins at all did, and one of them would read the
other's input list.

The naming half is not a hypothesis. Two independent conversions on a Pixel each computed
`cache/conversions/input_converted.mp4`, the second silently overwrote the first, and a tag query
in a fresh process then returned **two SUCCEEDED `WorkInfo`s naming that one file** with one file
on disk. That is the collision reaching the point where it makes a *fix* ambiguous rather than
just a file: `Reattachment` can offer the bytes, because they are the user's either way, but it
cannot say which job produced them.

`StagingNames` keys the name on the WorkManager request id. That id is what stays still across a
retry -- `WorkerWrapper` builds `WorkerParameters` from the `WorkSpec` id and only increments
`runAttemptCount` -- which matters more here than uniqueness does, and matters more since the
previous commit made retries routine. A failed attempt deletes its staged file on the way out,
and that only collects the partial the *previous* attempt left when the name has not moved.

Opaque rather than sanitised, deliberately. The staged name is never shown to anyone: `save()`
recomputes a suggested name and the user picks the real one in the SAF dialog. So there was
nothing to lose by dropping the display name, and something to gain -- a provider-supplied
display name can contain a separator, be empty, or be four kilobytes long, and `File(stagingDir,
"../escape_converted.mp4")` resolves to a path outside staging. That was reachable before this
commit and is now unreachable by construction rather than by a sanitiser that has to be right
about every case. There is a test for exactly that name.

The extension stays, and is not decoration: `FFmpegConcatCommand` names no output muxer, so
FFmpeg infers it from the output path. A fully opaque name would quietly produce the wrong
container.

`ConcatEngine`'s list file is derived from the output it belongs to rather than taking another
parameter, so the two cannot drift apart, a directory listing shows which list belongs to which
join, and the sweep ages them together.

Three neighbouring comments claimed things that are no longer true, and are corrected rather than
left to mislead the next reader:

  - `Reattachment.Ambiguous` said it "resolves on its own once each job stages under a name of
    its own". It now does -- for work enqueued from here on. The case is **kept**, because the
    queue outlives the change: WorkManager holds finished work for about a week, and the jobs
    likeliest to be sitting in it when this code first runs are the ones named the old way.
    Behaviour is unchanged and `ReattachmentTest` is untouched.
  - `OutputPublisher.sweepStaging` justified its age rule partly on there being "no per-job
    namespacing". There is now, and the rule still stands on its own: per-job names stop two jobs
    from sharing a file, and say nothing about whether a file's job is still running, which is the
    question a sweep actually asks. Same for `StagingSweep` and the note in
    `LibreMediaConverterApp`.
  - Both ViewModels' `reattach()` explained aliasing as something nothing prevented. Narrowed to
    what is still true of work already in the queue.

`ConcatEngineTest` asks `StagingNames` for the list file's name instead of spelling out
`concat_list.txt`. That is the difference between a test and a tautology: a literal there would
have gone on passing after the rename while asserting that a file nothing creates does not exist.
The same trap was live in the two worker tests from the previous commits, whose staged-file
assertions computed a path of their own -- they now assert on the staging directory being empty,
which cannot go vacuous when a name moves.

`PerJobStagingTest` drives the real worker, because the naming function was never the part that
was wrong: what was wrong was which name the worker asked for. Two jobs converting one file must
leave two files; a second attempt at one job must not leave a second; and a display name that
climbs out of staging must not. The first and third fail before the change with "each job must
have staged its own file, found [input_converted.mp4] expected:<2> but was:<1>" and "the output
belongs in staging expected:<1> but was:<0>" -- the latter because the file had landed in
`cacheDir` instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

app/src/main/java/org/libremediaconverter/LibreMediaConverterApp.kt

@@ -43,7 +43,7 @@ class LibreMediaConverterApp : Application() {
         //
         //  - Conversion and join outputs are written continuously, so a running job keeps
         //    its own mtime fresh and never looks abandoned.
-        //  - concat_list.txt is the one file written once and then only read, so it is the
+        //  - A join's list file is the one written once and then only read, so it is the
         //    one that has to be reasoned about rather than observed. A WorkManager attempt
         //    is capped by the six-hour-per-day foreground-service budget and a retry starts
         //    doWork() again from the top, rewriting the list file -- so no single attempt

app/src/main/java/org/libremediaconverter/convert/ConversionViewModel.kt

@@ -182,8 +182,8 @@ class ConversionViewModel @JvmOverloads constructor(
             if (_state.value !is ConversionState.Idle || activeWorkId != null) return@launch
 
             // Only a job that is the sole explanation for its staged file gets to name the input.
-            // When several jobs report the same file — which nothing prevents while the staging
-            // name is derived from the input's display name — the file is still the user's, but
+            // When several jobs report the same file — which staging on the job id has stopped for
+            // new work, but not for work already in the queue — the file is still the user's, but
             // saying which of them produced it would be a guess, so the card falls back to a
             // neutral label rather than borrowing the other job's.
             val tags = (reattachment as? Reattachment.Certain)?.job?.tags.orEmpty()

app/src/main/java/org/libremediaconverter/convert/OutputPublisher.kt

@@ -73,9 +73,10 @@ open class OutputPublisher(private val context: Context) {
      * Activity. [StagingSweep] owns the rule and its reasoning.
      *
      * Deliberately not the `clearStaging()` this replaces. That deleted the directory's
-     * whole contents, and the convert tab, the join tab and `ConcatEngine`'s
-     * `concat_list.txt` all share this directory with no per-job namespacing, so a blanket
-     * delete could destroy a live job's file.
+     * whole contents, and the convert tab, the join tab and `ConcatEngine`'s list file all
+     * share this directory — so a blanket delete could destroy a live job's file. Per-job
+     * staging names ([StagingNames]) stop two jobs from *sharing* a file; they say nothing
+     * about whether a file's job is still running, which is the question here.
      *
      * [nowMs] is a parameter so the clock is the caller's, not a hidden global.
      */

app/src/main/java/org/libremediaconverter/convert/StagingNames.kt

@@ -0,0 +1,52 @@
+package org.libremediaconverter.convert
+
+import java.util.UUID
+
+/**
+ * Gives every job a staging path of its own.
+ *
+ * `<cacheDir>/conversions/` is shared by the convert tab, the join tab and
+ * [org.libremediaconverter.ffmpeg.ConcatEngine]'s list file, and until this existed none of the
+ * three named a file that belonged to one job. A conversion derived its name from the input's
+ * display name, so two `holiday.mp4` from different folders collided; a join used the constant
+ * `joined.<ext>`, so any two joins of one format collided; the list file was the constant
+ * `concat_list.txt`, so any two joins at all collided.
+ *
+ * The collision was not theoretical. Two independent conversions on a Pixel each produced
+ * `cache/conversions/input_converted.mp4`, and a tag query in a fresh process returned two
+ * SUCCEEDED `WorkInfo`s naming that one file — which is what leaves reattachment unable to say
+ * which job the bytes on disk belong to.
+ *
+ * ## Why the job id, and why opaque
+ *
+ * The WorkManager request id is stable across retries: `WorkerWrapper` builds `WorkerParameters`
+ * from the `WorkSpec` id and only increments `runAttemptCount`. That matters more than uniqueness
+ * does — a retry runs `doWork()` from the top, and the delete on the way out of a failed attempt
+ * only collects the previous attempt's partial when the name has not moved.
+ *
+ * The staged name is never shown to anyone: `save()` recomputes a suggested name from the job's
+ * own spec, and the user picks the real one in the SAF dialog. So there is nothing to lose by
+ * making it opaque, and something to gain — the alternative was sanitising a provider-supplied
+ * display name, which can contain a separator, be empty, or be four kilobytes long. Naming the job
+ * retires that question instead of answering it.
+ *
+ * The extension is kept, and is not decoration. `FFmpegConcatCommand` names no output muxer, so
+ * FFmpeg infers it from the path; a name without the right extension would quietly produce the
+ * wrong container.
+ */
+object StagingNames {
+
+    /** The staging filename for the job with this [jobId], producing a file of type [extension]. */
+    fun forJob(jobId: UUID, extension: String): String = "$jobId.$extension"
+
+    /**
+     * The concat list file that belongs to the output staged as [outputName].
+     *
+     * Derived from the output rather than taken as another parameter, so the two cannot drift
+     * apart and so a directory listing shows which list belongs to which join. It ages with its
+     * output too, which is what [StagingSweep] needs.
+     */
+    fun concatListFor(outputName: String): String = outputName.substringBeforeLast('.', outputName) + CONCAT_LIST_SUFFIX
+
+    private const val CONCAT_LIST_SUFFIX = ".concat_list.txt"
+}

app/src/main/java/org/libremediaconverter/convert/StagingSweep.kt

@@ -12,9 +12,13 @@ package org.libremediaconverter.convert
  *
  * The rule replaces an unconditional `clearStaging()` that deleted the directory's whole
  * contents. That was hazardous: `<cacheDir>/conversions/` is shared by the convert tab, the
- * join tab and [org.libremediaconverter.ffmpeg.ConcatEngine]'s `concat_list.txt`, and any
- * two of them can be live at once, so a blanket delete could take a file out from under a
- * running job. Age is the narrowing.
+ * join tab and [org.libremediaconverter.ffmpeg.ConcatEngine]'s list file, and any two of
+ * them can be live at once, so a blanket delete could take a file out from under a running
+ * job. Age is the narrowing.
+ *
+ * Per-job staging names ([StagingNames]) do not change that. They stop two jobs from writing
+ * one file; they do nothing about a sweep deleting a file whose job is still running, which
+ * is what age is for.
  */
 object StagingSweep {
 
@@ -26,7 +30,7 @@ object StagingSweep {
      *
      * Twenty-four hours, chosen against the longest a live file can plausibly go untouched
      * rather than against how quickly cache should be reclaimed. Output files are written
-     * continuously, so a running job refreshes their mtime by itself. `concat_list.txt` is
+     * continuously, so a running job refreshes their mtime by itself. A join's list file is
      * the exception — written once and then only read for the rest of the join — so the
      * period has to exceed a whole join. WorkManager caps a single attempt at the
      * six-hour-per-day foreground-service budget and then stops the worker, and a retry

app/src/main/java/org/libremediaconverter/ffmpeg/ConcatEngine.kt

@@ -8,6 +8,7 @@ import com.arthenica.ffmpegkit.FFmpegKitConfig
 import com.arthenica.ffmpegkit.ReturnCode
 import kotlinx.coroutines.suspendCancellableCoroutine
 import org.libremediaconverter.convert.MediaProbe
+import org.libremediaconverter.convert.StagingNames
 import org.libremediaconverter.model.ConcatPlanner
 import org.libremediaconverter.model.ConcatStrategy
 import org.libremediaconverter.model.OutputFormat
@@ -43,7 +44,12 @@ class ConcatEngine(private val context: Context) {
 
         // The demuxer reads its input list from a file, which must live somewhere
         // FFmpeg can read; app cache is a real path, so it just works.
-        val listFile = File(output.parentFile, "concat_list.txt").apply {
+        //
+        // Named after the output rather than by the constant "concat_list.txt" it used to use.
+        // The constant meant any two joins running at once shared one list file, so one of them
+        // read the other's inputs -- and it is why a blanket sweep of the staging directory was
+        // never safe. See StagingNames.
+        val listFile = File(output.parentFile, StagingNames.concatListFor(output.name)).apply {
             writeText(FFmpegConcatCommand.listFileContents(paths))
         }
 

app/src/main/java/org/libremediaconverter/join/JoinViewModel.kt

@@ -93,14 +93,13 @@ class JoinViewModel @JvmOverloads constructor(
             // below, and both run on the main dispatcher, so nothing can interleave.
             if (_state.value !is JoinState.Idle || activeWorkId != null) return@launch
 
-            // Every join stages under the same constant name, so two finished joins always
-            // report the same file and no tag of either can be trusted to describe it. That is
-            // what Ambiguous means here, and the count falls back rather than being borrowed —
-            // which costs nothing in practice, since the count is only rendered while a job is
-            // live and a live job names no file to be aliased on. What it does not cover is the
-            // stream-copy-or-re-encode line on Joined, which comes from the picked job's output
-            // and can therefore belong to the other one. Same cause, same fix: one staging name
-            // per job.
+            // Joins used to stage under one constant name, so two finished joins always reported
+            // the same file and no tag of either could be trusted to describe it. That is what
+            // Ambiguous means here, and the count falls back rather than being borrowed — which
+            // costs nothing in practice, since the count is only rendered while a job is live and
+            // a live job names no file to be aliased on. Staging on the job id has closed that for
+            // new work, including the stream-copy-or-re-encode line on Joined, which comes from
+            // the picked job's output; joins already in the queue keep the old shape.
             val tags = (reattachment as? Reattachment.Certain)?.job?.tags.orEmpty()
             // Placeholders, and safe only because of where they can go. Joining reads nothing
             // but the size of this list, Waiting and Joined read none of it, and a reattached

app/src/main/java/org/libremediaconverter/work/ConcatWorker.kt

@@ -12,6 +12,7 @@ import androidx.work.WorkerParameters
 import androidx.work.workDataOf
 import kotlinx.coroutines.CancellationException
 import org.libremediaconverter.convert.ConversionDependencies
+import org.libremediaconverter.convert.StagingNames
 import org.libremediaconverter.ffmpeg.ConcatEngine
 import org.libremediaconverter.model.OutputFormat
 
@@ -49,7 +50,10 @@ class ConcatWorker(context: Context, params: WorkerParameters) : CoroutineWorker
 
         // Named before anything below can throw, so every exit has the handle to clean up with.
         // See the same line in ConversionWorker.
-        val staged = publisher.createStagingFile("joined.${format.extension}")
+        //
+        // Keyed on this job's id. The constant "joined.<ext>" this replaces meant any two joins of
+        // the same format wrote one file, and ConcatEngine's list file collided harder still.
+        val staged = publisher.createStagingFile(StagingNames.forJob(id, format.extension))
 
         return try {
             // Inside the try: a foreground start refused because the app is in the background --

app/src/main/java/org/libremediaconverter/work/ConversionWorker.kt

@@ -13,6 +13,7 @@ import androidx.work.workDataOf
 import com.arthenica.ffmpegkit.FFmpegKitConfig
 import kotlinx.coroutines.CancellationException
 import org.libremediaconverter.convert.ConversionDependencies
+import org.libremediaconverter.convert.StagingNames
 import org.libremediaconverter.model.AudioCodec
 import org.libremediaconverter.model.Container
 import org.libremediaconverter.model.ContainerCapabilities
@@ -73,7 +74,10 @@ class ConversionWorker(context: Context, params: WorkerParameters) : CoroutineWo
         // This only builds a path -- nothing is written until an engine opens it -- so naming it
         // early costs nothing, and it is what lets the catch collect a partial an earlier attempt
         // left behind under the same name.
-        val staged = publisher.createStagingFile(outputNameFor(displayName, spec))
+        //
+        // Keyed on this job's id rather than on the input's display name: two conversions of files
+        // that happen to share a name are two jobs, and used to be one file. See StagingNames.
+        val staged = publisher.createStagingFile(StagingNames.forJob(id, spec.extension))
 
         return try {
             // Inside the try, and that placement is the whole point. setForeground() throws
@@ -280,11 +284,15 @@ class ConversionWorker(context: Context, params: WorkerParameters) : CoroutineWo
         private const val TAG = "ConversionWorker"
 
         /**
-         * The staged and suggested filename.
+         * The name to suggest in the save dialog.
          *
          * The extension comes from the container and whether a video track survives, so Matroska
          * yields `.mkv` or `.mka` and MP4 yields `.mp4` or `.m4a` without a preset having to
          * enumerate both.
+         *
+         * No longer the staged name as well. Staging is keyed on the job id -- see [StagingNames]
+         * -- so this is only ever the string offered to the user, which is also what makes it safe
+         * for it to carry a display name the app does not control.
          */
         fun outputNameFor(inputName: String, spec: OutputSpec): String = inputName.substringBeforeLast('.', inputName) +
             "_converted.${spec.extension}"

app/src/main/java/org/libremediaconverter/work/Reattachment.kt

@@ -59,15 +59,20 @@ sealed interface Reattachment {
      *
      * Observed on a device rather than imagined: a tag query in a fresh process returned two
      * SUCCEEDED jobs whose output paths were both `…/conversions/input_converted.mp4`, with one
-     * file on disk. Nothing gives a job a staging path of its own — the name is derived from the
-     * input's display name — so a later conversion overwrites an earlier one's output while both
-     * jobs go on reporting that path as their result.
+     * file on disk. Nothing gave a job a staging path of its own — the name came from the input's
+     * display name — so a later conversion overwrote an earlier one's output while both jobs went
+     * on reporting that path as their result.
      *
      * The file is not the ambiguous part: whichever entry is picked, the user is offered the
      * bytes actually on disk, which is the thing that would otherwise be lost. What cannot be
      * recovered is which job wrote them, so the caller is told not to describe it. A card
      * labelled with the other job's input would be a confident lie, where a neutral label is
-     * merely thin. It resolves on its own once each job stages under a name of its own.
+     * merely thin.
+     *
+     * [org.libremediaconverter.convert.StagingNames] has since keyed staging on the job id, so
+     * nothing enqueued from now on can alias. This stays because the queue outlives the change:
+     * WorkManager keeps finished work for about a week, and the jobs most likely to be sitting in
+     * it when this code first runs are exactly the ones named the old way.
      */
     data class Ambiguous(override val job: JobSnapshot) : Reattachment
 
@@ -114,8 +119,8 @@ sealed interface Reattachment {
          * Live work outranks a finished result because a running job is holding a foreground
          * notification: someone opening the app while that notification is in the shade expects
          * to find that conversion, not a result from yesterday. It is also the right answer when
-         * the running job is overwriting the older one's staged file, which a shared staging name
-         * allows.
+         * the running job is overwriting the older one's staged file, which work enqueued before
+         * per-job staging names can still do.
          *
          * Within a rank the **newest staged file** wins, and that is not a detail. Losing a tie
          * is not the same as waiting for the next launch: the query has no `ORDER BY`, so its