Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot save State over Samba share #63

Open
GoogleCodeExporter opened this issue Aug 23, 2015 · 2 comments
Open

Cannot save State over Samba share #63

GoogleCodeExporter opened this issue Aug 23, 2015 · 2 comments

Comments

@GoogleCodeExporter
Copy link

1. Open a ROM and select File > Save State
2. Point to a Samba share and try to save your state there
3. snes9x-gtk output the following error message: "Couldn't set ownership of 
file." and the state is not saved (erroneous file, 10 bytes size).
4. Loading this erroneous state file will lose all your game progression (.srm 
file is overwritten with "nothing"!). I have to restart my game from the 
beginning!!

Using Snes9x 1.53, GTK+ port version 82 under XBMCbuntu Eden.

The problem seems to be located in gtk_file.cpp around line 300:
- The "chown" command is executed even if the owner of the file already is the 
current user.
- If this command fails (with samba it returns "Function not implemented"), 
then the write access rights should be enough to save the file.
- The erroneous, almost empty State file should NOT be produced.
- Loading such a file should not reset your .srm file.

However, saving the .srm file on a Samba share works fine.
Moreover, I would have been happy to be able to recover my .srm file with an 
"autosave" feature which would save it using an unique name (e.g. including the 
date and time). 

Thanks a lot!

Original issue reported on code.google.com by [email protected] on 22 Apr 2012 at 8:33

@GoogleCodeExporter
Copy link
Author

This code is broken and should have been removed ages ago. Removing that block 
should get rid of the chown error and the empty output file. The snapshot code 
is extremely lenient about what it accepts because of compatibility concerns, 
so I'm not sure what we can do about loading a faulty file when it's impossible 
to verify that the contents aren't exactly what's intended.

Original comment by [email protected] on 23 Apr 2012 at 6:38

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

About the faulty files: we should just do nothing when the file is recognized 
as faulty (and is is, since an error message is output). We could actually get 
rid of the chown block. Thanks!

Original comment by [email protected] on 23 Apr 2012 at 7:19

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant