Cannot play ROMs in specific folder with RetroArch

I don’t know if “kernel” is the right place for this, but cp is a basic linux functionality so i suppose it’s here.

Anyway i just get a wild bug, a strange one… i want to understand what is going one.
I download a mame romset, and use a copy command to “extract” specific list of roms in a folder. Thing is, for some times a specific rom folder do not work when i try to start the game on mame. I thought it is a mame bug, that this specific machine is broken right now, so i let it be, but tonight i did some investigation and this is strange.

My (limited, only for exemple) cp command look like this :
cp /home/XXX/Divers/Gaming/Archive/MAME_0.232_ROMs_Merged/{,} /ssd1/Home/Divers/Gaming/Arcade_Roms/PGM/
If i do this the two files and are probably corrupted because mame cannot start the rom, i get a black screen. Roms seems ok as they have the right “weight”. Same problem for any other roms from the same set. Now if i use mame to start the rom from the original (MAME_0.232_ROMs_Merged) folder, games start just fine.

So i try a few things, and arrive to this conclusion : if i copy a rom to the PGM folder with the cp command, it is systematically corrupted, and only with this folder and the cp command. If i copy manually with a file manager like dolphin to the PGM folder, the rom starts ok. If i delete the PGM folder, create a new, or name it pgm instead, same problem, roms are corrupt.
I try to copy the roms to folders with new name, in my “Arcade_Roms/” folder or anywhere else, and again no problem. So this problem is specific to the cp command and “pgm” name folder.

Also it could be only the bios file “” that could be corrupted, so the roms cannot boot, i don’t know. Maybe cp don’t like to copy a file to a folder with the same name, who knows. Maybe someone have an explanation because i find this one very strange. I run several other cp commands and have no problems with the other folders.

Could it be a problem with my file system ?

It’s a question where you assume that we can infer
and know
what is in the source MAME_0.232_ROMs_Merged directory

… how about you just copy like this:
cp /home/XXX/Divers/Gaming/Archive/MAME_0.232_ROMs_Merged/* /ssd1/Home/Divers/Gaming/Arcade_Roms/PGM/

… copy everything from MAME_0.232_ROMs_Merged to the …/Arcade_Roms/PGM/ directory

cp is not picky - it copies everything you give it

but I don’t know what your

in that command actually resolves to

What is this … thing - and how do you start it
Maybe that is the reason why it complains not finding files?

No one knows about what filesystem you use where …
so: yes
could be - or not …

You can also use rsync -ahr /path/to/source /path/to/destination.


Ok i will explain it again… the source directory, in our case MAME_0.233… have 13k+ files on it, i don’t care for 99% of these games, so i use a cp command to extract a few files to other folder to sort them. I use a cp command because mame romset are update at every release. These files correspond to rom and bios files, specific to a machine i want to emulate.

The complete command is this for exemple, and will copy all the polygamemaster rom to the PGM folder :
cp /home/XXX/Divers/Gaming/Archive/MAME_0.232_ROMs_Merged/{,,,,,,,,,,,,,,,,,,} /home/XXX/Divers/Gaming/Arcade_Roms/PGM

Of course all these mame things are irrelevant, it’s just data i am copying… it could be my holiday pictures it’s not the problem. The problem is cp command is corrupting my data when i copy to this specific folder, god knows why.
I have similar command to extract rom from other machine to their specific folder, and every-time it is working fine, except this PGM folder weirdness .

The problem is not hard to avoid, i can just create folder “polygamemaster” or anything i want, instead of “pgm”, and cp command is working. I don’t come here to avoid the problem, i want to have an explanation, it’s very weird.
As for my file system it’s btrfs mounted with standard manjaro option, including compression with zstd.

You want something weirder. I try the rsync command you gave me, so i just did
rsync -ahr /home/XXX/Divers/Gaming/Archive/MAME_0.232_ROMs_Merged/ /home/XXX/Divers/Gaming/Arcade_Roms/PGM
rsync -ahr /home/XXX/Divers/Gaming/Archive/MAME_0.232_ROMs_Merged/ /home/XXX/Divers/Gaming/Arcade_Roms/PGM

I deleted the PGM folder yesterday, so i create it again before executing the command.
The data are also corrupted with the rsync command, impossible to start these files with mame. I try the command to copy to another folder (PolyGameMaster for exemple) and this is working. :face_with_raised_eyebrow:
I just try a manual copy / paste and it seems the date get also corrupted.

I can make a video of the problem, this is really weird. This “PGM” folder is cursed i guess lol.

I’m trying to follow along, but I humbly ask that you format your posts to make the code easier to read. :pray:

Right off the bat, you might be looking at an issue with BTRFS inline compression. You can test this out on the “corrupt” files by feeding the first part of the file through a hex reader. If you see references to “zstd” or other compression, then you have an issue.

… looks like it :wink:
Very weird indeed -
cp working as intended when copying to any folder, but as soon as that folder is named PGM in this specific path:


the files are somehow corrupted

You say they have the same “weight” - you likely mean: same size?
ls -al of the same named file
after the copy action
would show the very same size in both source and destination directory?

If so, you can further compare them
diff /home/XXX/Divers/Gaming/Archive/MAME_0.232_ROMs_Merged/ /home/XXX/Divers/Gaming/Arcade_Roms/PGM/
for example
and see whether they are different.

To see where they might differ
can be used

similar command as with diff
adapt to your needs, for example according to this here:

where this comparison is taken even further.

… there should be differences in between files copied to your PGM folder
and the same files copied to a folder with some other name

Actually: there really should definitely NOT be any difference - but you say there is …

One possibility is that the files are not being decompressed (from their disk state) before being read into RAM. This has happened with ZFS before (with inline LZ4 compression), so it’s not beyond the realm of probability that this can occur with BTRFS with inline ZSTD compression as well, when it comes to certain scenarios.

Can you share your filesystem and partition layouts?


I try to compare the files and indeed they have the same size, i try the diff command and it doesn’t show anything. I also try different checksum (MD5, SHA1, SHA256, SHA512) and they are the same.
I start to think the problem is not the files, but MAME that don’t like this folder for some reason.

It could also be a btrfs problem of some sort, in the last few month i have to hard shutdown my computer a lot of time because of a bug. I have two monitor hook up to my graphics cards, a TV and a standard lcd monitor in displayport. Often when the LCD monitor was powered on or leave a power saving state, manjaro just freeze. Monitor stay black and say there wasn’t anything connected to it, and it seems manjaro was crashed. Recently there was a big update that seems to resolve the problem. But all these unclean shutdown are not extremely good for file system i suppose. I did check with gparted sometimes ago to see if there is any damage to the file system without anything. I will run another test.

As for my system i have 2x 8TB SSD in Sata, 2x NVME (8TB and 1 TB).

sda           8:0    1   7,3T  0 disk 
└─sda1        8:1    1   7,3T  0 part /ssd2
sdb           8:16   1     7T  0 disk 
└─sdb1        8:17   1     7T  0 part /ssd3
sdc           8:32   1  58,4G  0 disk 
└─sdc1        8:33   1  58,4G  0 part 
nvme0n1     259:0    0 931,5G  0 disk 
├─nvme0n1p1 259:1    0   500M  0 part /boot/efi
├─nvme0n1p2 259:2    0  15,6G  0 part 
├─nvme0n1p3 259:3    0  87,9G  0 part /var/log
│                                     /var/cache
│                                     /home
│                                     /
├─nvme0n1p4 259:4    0    16M  0 part 
└─nvme0n1p5 259:5    0 827,5G  0 part 
nvme1n1     259:6    0     7T  0 disk 
└─nvme1n1p1 259:7    0     7T  0 part /ssd1

So there’s no data corruption.

Maybe the PGM folder is a particular name that the MAME emulator doesn’t like? :person_shrugging: This entire issue is just weird at this point.

Yes i create a new PGM2 folder, use my cp command and try to open it with mame. It is working fine…

As for the required rom, the is the bios file and need to be in the same folder as them game rom file, in my case i always tried to open which is the game (demon front) and include the bios file in the same folder.

I just tried another thing. I do have another pc and i tried the same thing. The behavior is the same, mame cannot start any rom in the pgm folder but any other folder is fine.

I suppose it will close the investigation. It stay very weird but the issue have nothing to do here, i should see this with retroarch directly.

Thank you for your help and your time.

So if you rename that folder from PGMPGM2 then it will work fine?

The opening post led us towards a conclusion of “data corruption” from the cp command, when copying to a certain folder. This leads everyone who tries to help on a wild goose chase. Kernel issue? Filesystem issue? Hardware issue? RAM? CPU? Drive?

But then everything is fine the entire time (the files are identical in size and checksums). This should have been ruled out from the very start. Why assume the data is corrupt without confirming it?

And it appears this is an issue restricted to a game emulator. It could be for any reasons. Maybe the PGM name is reserved for something else in RetroArch? Maybe there’s a setting in RetroArch that is to blame? For all we know, maybe those zip files need to be in the presence of other files in the same folder or with a relative folder?

But this no longer looks like a cp or “data corruption” issue anymore.

A better thread title would have been: Cannot play ROMs in specific folder with RetroArch

1 Like

Agreed and title adjusted.