Sonic 2 Xenowhirl disassembly messing with Windows file permissions

For some reason seemingly at random, my hack will change the file permissions (the ownership of the file) for one of the files in the disassembly during the build process, and prevent me from building a rom until I do some stupid advanced windows shit to fix it (which takes an annoyingly long time). It seems to happen every other time I build, and it's pretty much brought my hacking to a halt, as I have to wait about five minutes (more if the issue pops up twice in a row :C) between edits. Does anyone have any idea why this is happening, or what could be done to stop it? It's really grinding my nerves right now.

 

I always use Xenowhirl, but never experienced this.  Which file does it lock?

 

I'm not sure, I just fix the issue by changing the ownership of every file in the disassembly at once. I highly doubt that it's any of the art, code, etc. as it all loads in my usual editors just fine. I think the last time I tried to track it down, it was one of the files named "s2.(some random letter here)" in the main folder, but I'm not to sure.

 

Shot in the dark, but s2.p and s2.h are AS output. Xeno uses a fairly old version of AS; would updating it, preferably to what the Git disasm uses, do anything?

 

If you want to track down which file(s) get locked, and you know how to operate a command prompt, you can use the CACLS command specifying *.* as argument to get a listing of the permissions of all the files in a directory. Since it's a quite long output you should direct it to a file rather than to the console, e.g.

Code:

C:\something>CACLS *.* > mylog.txt

Anyway, given what Clownacy said above (s2.p and s2.h are the output of a program), I'm wondering if it's a case of wrong permissions on a parent directory, which wouldn't affect existing files (e.g. asm files and resource files), but would affect newly created files (overwritten files such as those are equivalent to newly created files in some cases).

 

Clownacy: How would I go about doing that? Usually, I'd just start copy/pasting stuff, but I don't know what each assembler requires, and I don't what to completely screw over my disassembly.

Nineko: Putting that in a Batch file (with a corrected file path, of course) results in an empty text file. Putting it in the command prompt makes it insist that the file path is not a proper command; either the syntax is off, or I'm screwing up in a way I can't quite see...

 

You don't type in the "C:\something>", that's just an example of what the prompt might look like. You only type "CACLS *.* > mylog.txt" (without quotes).

 

Here's a copy of the output file. Again, I'm not 100% sure what it means, but it seems to suggest that all the main files and folders are fine.

P.S. To protect my identity, I've replaced every instance of my user name with "Pacguy". The original user name does in fact contain a space, if that matters. Also, Some files are owned by the built in "hidden admin", as I've been using it to fix the permissions issues.

View attachment mylog.txt

 

​In win32, copy across asw.exe and the msg folder. It might be worth copying over libgcc_s_dw2-1.dll and libstdc++-6.dll, too.

 

Updating asw.exe seems to have fixed it. Thanks for all the support guys :3

 

The issue is back... AGAIN. It seems rarer, which is nice, but it's still there...

P.S. Double post to ensure that people come back to the topic and know the problem isn't solved...

EDIT: Nevermind, the problem is REALLY rare now. I can haxors normally now. Thanks again :3

 

​Well, for the lack of a better word, all those "F" letters mean that you have "Full" permissions on all the files, so yeah the problem has to be somewhere else and I'm glad to read it got better with Clownacy's suggestion. You should run a CACLS on the parent directory to be extra safe, but...