Re: [Warzone-dev] Fixing directories
On Monday 08 September 2008 06:03:08 bugs buggy wrote: If you want to add all the files/directories in base, one by one, then remove them one by one, checking no file handle is open, that seems to be a overly complex way to handle this. I just assumed PhysFS could tell us... I didnt try to think of some crazy way of hacking it. least one file handle is open, (in this case, it happens to be the music one) and physfs won't allow it to be removed from the search path (which is correct behavior IMO) so it fails. If PhysFS rejects removing that directory, it seems pretty much fine to me... The whole search path thingy (on our end) needs to be revised anyway. Now with the knowledge that we cannot just purge it and recreate it whenever we want. The current behaviour (reject unmounting a dir, and mount other dirs on top of it) seems fine to me and we should make use of it, rather than hack around it in weird ways... I was thinking of something along the lines of: Warzone Warzone/data Warzone/data/base Warzone/data/mods Warzone/data/mp Warzone/data/music Warzone/data/music/music* You'd have to do that for several more directories, and it would not really be clean imo... There is also a configdir/music directory (which overrides the other music folder) which needs to be removed, unless, we will allow sharing of music tracks between people? AFAIK, this is left over behaviour from before, and not really needed. userdir/music is not left over from before or not really needed... What is in userdir is what the user chooses over the system installation... And that needs to stay... Remember, there exist so called multi user operating systems... *since the source has 'music' hardcoded (static const char UserMusicPath[] = music;), rather than changing allot of things around, I did it the simplest way to prove this is the problem. I dont think we should change that hardcoding. Maybe just move it somewhere where it is obvious it is not something to choose or a config setting, but a constant, a name for a magic value. (In case it is used more than once. Otherwise a string by itself should be pretty selfexplanatory.) Question: This is the cause for the PhysFS crashes we are experiencing, right? --Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Fixing directories
On Sunday 07 September 2008 23:01:08 bugs buggy wrote: Ok, the issue is, that we open the music file. (in base/music). Then we want to remove base, since we are going to play a MP game. But we can't since we still have a open file handle. This leaves it in the physfs search path, and causes us issues. You mean when we start the game we are in base mode? SearchPath#base When we then start an MP game we switch to mp mode? SP#mp Correct till now? That causes issues when files from base are still opened when the searchpath is removed? So why dont we just add directories? And before removing any make sure there are no open files? SP#base:mp The no-open-files part would have to be out of the system itself, I think. Checking all open files and refusing to unmount (or closing files on unmount) doesnt sound very clever. --Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Fixing directories
On 9/7/08, Dennis Schridde [EMAIL PROTECTED] wrote: On Sunday 07 September 2008 23:01:08 bugs buggy wrote: Ok, the issue is, that we open the music file. (in base/music). Then we want to remove base, since we are going to play a MP game. But we can't since we still have a open file handle. This leaves it in the physfs search path, and causes us issues. You mean when we start the game we are in base mode? SearchPath#base When we then start an MP game we switch to mp mode? SP#mp Correct till now? That causes issues when files from base are still opened when the searchpath is removed? So why dont we just add directories? And before removing any make sure there are no open files? SP#base:mp The no-open-files part would have to be out of the system itself, I think. Checking all open files and refusing to unmount (or closing files on unmount) doesnt sound very clever. --Devu Huh? How are you supposed to tell which file is open? All we know is that at least one file handle is open, (in this case, it happens to be the music one) and physfs won't allow it to be removed from the search path (which is correct behavior IMO) so it fails. I am unaware of a way to check just which file(s) we have open unless you keep them in a list. If you want to add all the files/directories in base, one by one, then remove them one by one, checking no file handle is open, that seems to be a overly complex way to handle this. I was thinking of something along the lines of: Warzone Warzone/data Warzone/data/base Warzone/data/mods Warzone/data/mp Warzone/data/music Warzone/data/music/music* There is also a configdir/music directory (which overrides the other music folder) which needs to be removed, unless, we will allow sharing of music tracks between people? AFAIK, this is left over behaviour from before, and not really needed. The above is what my patch does, and I did test it, and it works. It should also fix bug https://gna.org/bugs/?12280 https://gna.org/bugs/?11847 patch here: http://developer.wz2100.net/ticket/57 *since the source has 'music' hardcoded (static const char UserMusicPath[] = music;), rather than changing allot of things around, I did it the simplest way to prove this is the problem. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
