"Trash auto-generated files" setting doesn't remove *seg* files after export

[snakecase]

I have a lot of issues to go through, so in order to make it easier for me to help you, I ask that you please try these things first

• Try with the newest version from GitHub
• Read the documentation and FAQ, Known issues, Troubleshooting
• Search for your problem under Issues or Discussions
• If you have a problem only with a particular file (or file type), use this form instead
• Windows 7, 8 and 8.1 are no longer supported. This is not a question about Windows 8.1 or older.

Operating System

Windows 10

Steps to reproduce

1. Go to File → Settings
2. Find Cleanup files after export setting
3. Press Change preferences button
4. Enable Trash auto-generated files setting
5. Enable Do all of this automatically after exporting a file? setting
6. Open any *.mp4 file
7. Set a few segments
8. Export with Merge cuts mode selected
9. Take note of new files in the export folder
   
   

Expected behavior

*seg* files are not present in export folder.

Actual behavior

*seg* files are present in export folder:

Share log

No response

[mifi]

are you sure that your export folder was empty before you ran the test (e.g. test-*-seg*.mp4 was not there before)? I cannot reproduce this problem. for me it will auto-delete seg1 and seg2 after merging.

[snakecase]

are you sure that your export folder was empty before you ran the test (e.g. test-*-seg*.mp4 was not there before)? I cannot reproduce this problem. for me it will auto-delete seg1 and seg2 after merging.

Yes, created it specifically for this bug report and put test.mp4 inside, nothing else.

[mifi]

I don't understand how this can happen. LosslessCut has always worked in this way that when you export with "merge" mode, it will delete the two segments after merging, regardless of "cleanup files" settings (even before that setting was introduced). Only if you use merge&separate export mode will it keep the seg files after merging.

[snakecase]

Indeed. I forgot to mention that this bug showed up in the latest version. Before that I was using 3.54.0 without problems. Tried cleaning LC settings from AppData but no luck. Would be happy to provide logs if you point me to the path.

app.log seems useless in this regard. Right after export:

...
2023-09-06T09:24:21.575Z info: Found running instance, quitting
2023-09-06T09:25:06.012Z info: Initializing config store
2023-09-06T09:25:06.043Z info: Waiting for app to become ready
2023-09-06T09:25:06.046Z info: CLI arguments { _: [] }
2023-09-06T09:25:06.735Z info: Current version 3.56.0
2023-09-06T09:25:06.735Z info: Newest version 3.56.0
2023-09-06T09:33:26.542Z info: Initializing config store
2023-09-06T09:33:26.574Z info: Waiting for app to become ready
2023-09-06T09:33:26.577Z info: CLI arguments { _: [] }
2023-09-06T09:33:27.337Z info: Current version 3.56.0
2023-09-06T09:33:27.337Z info: Newest version 3.56.0
2023-09-06T09:36:37.854Z info: Initializing config store
2023-09-06T09:36:37.897Z info: Found running instance, quitting
2023-09-06T09:42:55.084Z info: Initializing config store
2023-09-06T09:42:55.127Z info: Found running instance, quitting
2023-09-06T09:46:03.112Z info: Initializing config store
2023-09-06T09:46:03.154Z info: Found running instance, quitting
2023-09-06T10:00:51.096Z info: Initializing config store
2023-09-06T10:00:51.145Z info: Found running instance, quitting
2023-09-06T10:03:06.163Z info: Initializing config store
2023-09-06T10:03:06.207Z info: Found running instance, quitting
2023-09-06T10:04:12.583Z info: Initializing config store
2023-09-06T10:04:12.618Z info: Found running instance, quitting
2023-09-06T10:06:25.144Z info: Initializing config store
2023-09-06T10:06:25.181Z info: Found running instance, quitting
2023-09-06T10:07:58.333Z info: Initializing config store
2023-09-06T10:07:58.370Z info: Found running instance, quitting
2023-09-06T12:34:16.100Z info: Initializing config store
2023-09-06T12:34:16.158Z info: Waiting for app to become ready
2023-09-06T12:34:16.168Z info: CLI arguments { _: [] }
2023-09-06T12:34:16.714Z info: Current version 3.56.0
2023-09-06T12:34:16.714Z info: Newest version 3.56.0
2023-09-06T13:21:50.647Z info: Initializing config store
2023-09-06T13:21:50.687Z info: Found running instance, quitting

From Help → Report an error menu:

No error occurred.

{
  "state": {
    "ffmpegExperimental": false,
    "preserveMovData": false,
    "movFastStart": true,
    "preserveMetadataOnMerge": false,
    "filePath": "",
    "externalFilesMeta": {},
    "mainStreams": [],
    "copyStreamIdsByFile": {},
    "cutSegments": [
      {}
    ],
    "mainFileFormatData": [],
    "rotation": 360,
    "shortestFlag": false,
    "effectiveExportMode": "merge",
    "outSegTemplate": "${FILENAME}-${CUT_FROM}-${CUT_TO}${SEG_SUFFIX}${EXT}"
  },
  "platform": "win32",
  "version": "3.56.0"
}

[mifi]

hmm, are you still having this issue? did you see any errors in the developer tools? also what time did the export happen relative to your app.log? did you export right before the first line? (2023-09-06T09:24:21.575Z info: Found running instance, quitting)

[snakecase]

Yeah it still occurs in the latest 3.59.1.0. Not sure why I didn't check Developers console log in the first place but the culprit is found!

index-18074aaf.js:298 Cleaning up files Object

index-18074aaf.js:166 Failed to delete C:\Users\USERNAME\Desktop\RC\New folder\2023-12-27 21-45-22 (GMT p5)-merged-1703933052361-00.01.04.915-00.01.07.424-seg1.mp4 Error: EPERM: operation not permitted, unlink 'C:\Users\USERNAME\Desktop\RC\New folder\2023-12-27 21-45-22 (GMT p5)-merged-1703933052361-00.01.04.915-00.01.07.424-seg1.mp4'
(anonymous) @ index-18074aaf.js:166

index-18074aaf.js:166 Failed to delete C:\Users\USERNAME\Desktop\RC\New folder\2023-12-27 21-45-22 (GMT p5)-merged-1703933052361-00.01.40.427-00.01.43.415-seg2.mp4 Error: EPERM: operation not permitted, unlink 'C:\Users\USERNAME\Desktop\RC\New folder\2023-12-27 21-45-22 (GMT p5)-merged-1703933052361-00.01.40.427-00.01.43.415-seg2.mp4'
(anonymous) @ index-18074aaf.js:166

index-18074aaf.js:166 Failed to delete C:\Users\USERNAME\Desktop\RC\New folder\2023-12-27 21-45-22 (GMT p5)-merged-1703933052361-00.03.16.670-00.03.21.342-seg3.mp4 Error: EPERM: operation not permitted, unlink 'C:\Users\USERNAME\Desktop\RC\New folder\2023-12-27 21-45-22 (GMT p5)-merged-1703933052361-00.03.16.670-00.03.21.342-seg3.mp4'
(anonymous) @ index-18074aaf.js:166

-1703933186636.log

[mifi]

That’s odd. It seems it was also unable to set timestamp on the merged output file 1703933052361-cut-merged-1703933070237.mp4

do you know why it would not be able to write to these files? Is there some rule in the operating system or anti-virus blocking write access to the file? Are you able to rename the file to something else or do you also get permission denied?

[snakecase]

Damn you are right. It is indeed an anti-virus issue. Disabled it (Avast), restarted LC and it works like a charm now. But I'm not certain that Avast blocks the app (it would notify me in such case). Looks like it processes files that LC outputs during export and somewhere at that time LC's file deletion breaks.

[mifi]

Omg! How can antivirus software block the application that created a file from accessing its own file? This is such an invasive «check» that would break a lot of apps. Antivirus is nothing but trouble if you ask me! At least we know which antivirus to stay away from (Avast).

I guess losslesscut should either:

• warn the user that they need to change/disable antivirus software
• retry the delete operation (not sure if that will even work and for how long one has to retry in order to be sure

[snakecase]

As I said before it probably doesn't block the app but maybe reads segment files that the app outputs and that coincidentally breaks the deletion. On the other hand it seems that EPERM: operation not permitted, unlink... is a widespread issue though not sure our case applies here.