Option to prevent sets with excess files when raw-copying #941
Comments
|
I think there might be some confusion with how arcade ROM sets are merged or split. To help diagnose, could you provide the following:
|
|
Originally when I didn't specify the Running the above command with Here are the two files: The input and output directory is the same, so the contents of Here's that part of the dat file if you want it: That is the order they are in the file as well. Also, I get these warnings on the command output: If I run the exact same command again, it leaves the two files alone, no warnings or anything. That's expected though. I find it weird that igir will copy the zip file over if you don't specify the |
Interesting, I didn't know that there were clones that did this.
|
Ignore my other comment, I misread your comment. |
|
I'm thinking a new I'll have to think about it because I'm worried |
Ah, yes that makes sense.
Yeah I think that would be confusing, and at least the way I use it (and I think you do as well), I expect move to reorganize my collection (input and output are the same directory, basically a rename) as well as move in new files from additional paths at the same time. I think I saw that in your real world use script. I guess there's two ways of looking at it, either you want to complete the collection, or you want to make sure your current collection is correctly organized. In the former, you want your source of roms (itself and any add on paths) to all come together and make as many complete sets as possible. In the latter, you'd want each existing file to be matched up to the closest matching DAT entry, and updated/renamed to match. By default igir has the former mindset, and --single almost covers the latter one, just that if your collection contains a parent and a clone archive, the clone will always be removed. So maybe there just needs to be an argument that turns off greedy mode, where igir will evaluate each archive in its current state and see which DAT entry most closely matches it, and then goes with that. Not sure how complicated that would be though. |
|
I'll have to think about the naming of it, but an option to complement |
emmercm
changed the title
|
The merging of #1034 didn't resolve this issue for some reason. |
🔒 Inactive issue lockThis 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. Comment generated by the GitHub Lock Issues workflow. |
Is your feature request related to a problem?
I'm sorry, this is probably the last request!
If I have a folder with this fbneo file in it:
And I run igir like this:
I get an extra file created:
I don't want that extra one being made. I tried using the
--singleargument, which does prevent the new one being created, but in my actual directory of roms it deletes some of the clones that I actually want to keep around with their parents.Describe the solution you'd like
Either some way to specify roms to ignore in the
--singlelogic, or have a command line argument to disallow creating new roms. Moving/renaming and copying can still happen, but new ones can't be built from existing ones.Additional context
My initial solve for this was the "don't create new roms" thing, and had a whole feature request made for it, until I discovered the
--singleargument. Using that on my test above, it fixed it, so canceled the feature request before submitting it. After I discovered it messed with some of my roms, I rewrote this.I'm not sure how "don't create new roms" would work with multiple input sources though. If the input is the same as output, then only move/renames would be allowed, and thus no creations of new roms could occur. But if the input isn't the output, I guess the move or copy would go to whatever rom matches the best?
The text was updated successfully, but these errors were encountered: