Closed MisterTea closed 8 years ago
Please try importing via the ( + ) button on the bottom left and see if that works.
I stepped through the debugger and found the issue: it can't write the extracted file because my roms folder isn't writable. Can we change that logic to write the extracted file to the /tmp directory?
Created a PR. Works on my system: let me know what you think.
You had said earlier that your extracted folder WAS writable...
I was wrong, sorry. I thought it was writable but I just verified that it isn't:
touch: /Volumes/pawn/test: Read-only file system
Hmm, it looks like the sram is based on the game location, so this PR will cause sram to go into a temp folder, which is not great :-/
Please try importing via the ( + ) button on the bottom left and see if that works.
Did you look at my PR? There's no way importing from the + button is going to fix the case where your rom zips are in a read-only folder.
Thanks for submitting the PR, but there's some more changes across the source that need to be done in order to make unzipping to a temp folder work. For starters, VideoItem
needs additional properties that will hold the save, save state and system paths separate from the game path itself. I don't plan on working on VideoItem
as we're already at work on a replacement system for the backend, #162.
As for the weirdness caused by importing a zip directly, we'll just have to disable dragging and dropping for the pre-alpha target if we can't find a quick fix.
Why not chnge the permissions of the file with QFileDevice or omething like that. Like check the permissions and then change
On Tue, Oct 20, 2015 at 5:57 PM, athairus notifications@github.com wrote:
Thanks for submitting the PR, but there's some more changes across the source that need to be done in order to make unzipping to a temp folder work. For starters, VideoItem needs additional properties that will hold the save, save state and system paths separate from the game path itself. I don't plan on working on VideoItem as we're already at work on a replacement system for the backend, #162 https://github.com/team-phoenix/Phoenix/issues/162.
As for the weirdness caused by importing a zip directly, we'll just have to disable dragging and dropping for the pre-alpha target if we can't find a quick fix.
— Reply to this email directly or view it on GitHub https://github.com/team-phoenix/Phoenix/issues/190#issuecomment-149748205 .
Things are just incomplete at this stage.
Here's what's missing:
User Data
alsoVideoItem
needs to have additional properties for Core
to useAlso his volume was mounted read-only. That's not something we can change. I think it's safe to assume that from now on the folder that contains your games may not be writable. Best to keep everything that needs to be written under User Data/
It might also help to detect when Phoenix is launched from a read-only volume and either warn the user and not write anything or refuse to run.
This issue is blocked until these changes I've proposed are rolled into #207
Unzipping to a temp directory has been fixed as of https://github.com/team-phoenix/Phoenix/commit/91a4942f6fc29b34bbb09ab200f07cde7c061853.
Proper game scanning for .zip files is in progress in the corecontrol
branch. Bug will be closed once this branch is merged into master
.
Branch corecontrol
has been merged, zip files now work perfectly along with drag & drop. Closed!
Thanks for your hard work!! On Mon, Nov 9, 2015 at 7:07 PM athairus notifications@github.com wrote:
Branch corecontrol has been merged, zip files now work perfectly along with drag & drop. Closed!
— Reply to this email directly or view it on GitHub https://github.com/team-phoenix/Phoenix/issues/190#issuecomment-155269543 .
I dragged a folder with a zip into Phoenix, then tried to run the zip. Note that Phoenix found the artwork for the game so that seems to be correct, but the code that launches the game doesn't handle zip correctly at the moment:
Log: