Pandora Directory Structure Question


WhiteBat said:
dflemstr said:
Could someone pretty please put a site map on the wiki? It's impossible to find any pages without knowing the link beforehand.
You can always search for "pnd"... Or look in the PND category: http://pandorawiki.org/Category:pND or in the FAQ category: http://pandorawiki.org/Category:FAQ etc.
 
Last edited by a moderator:
"Having to tidy up your appdata folders once you delete a PND" is roughly in line with "having to delete your PS2 saves when you sell a game".

I say PS2 saves rather than xbox saves, because it's a lot more "work" in terms of menu steps to get to the general xbox360 "saved games on your hdd" manager than it was to deal with PS2 saves.

I think the "PNDs are like game discs, appdata is gamesaves" metaphor is perfectly sensible, both in the context of the Pandora being a console and it being a computer. Just as long as it's fairly easy for the user to discover it, both so they can put extra files in the right place (roms for emulators, etc.) and also tidy up anything that's now wasting space. A shortcut labeled "game saves and configs" on the standard desktop (and something similar in the easier launcher things) would do just fine.
 
dflemstr said:
WhiteBat said:
Could someone pretty please put a site map on the wiki? It's impossible to find any pages without knowing the link beforehand.
You can always search for "pnd"... Or look in the PND category: http://pandorawiki.org/Category:pND or in the FAQ category: http://pandorawiki.org/Category:FAQ etc.
"PND" search returns no results. That'll stop most people in their tracks, they won't go looking for categories. I think at the least the main page needs a few more links, PND and USB being the obvious ones. I believe only Chip can do this.
 
Last edited by a moderator:
dflemstr said:
You can always search for "pnd"... Or look in the PND category: http://pandorawiki.org/Category:pND
1603hmu.jpg
HOW DID YOU GET TO THAT PAGE?!??
 

Attachments

  • 1603hmu.jpg
    1603hmu.jpg
    4.2 KB · Views: 120
Last edited by a moderator:
:lol: exactly. Dflemstr I love your work and your brain, but you have to remember that probably less than 10% of people think so efficiently. Everyone else needs shiny buttons. Even Pandora owners.
 
Gruso said:
"PND" search returns no results. That'll stop most people in their tracks, they won't go looking for categories. I think at the least the main page needs a few more links, PND and USB being the obvious ones. I believe only Chip can do this.
Yeah I noticed, the search is completely broken. What's up with that?

Anyways, does anyone know how to reach Chip? And who is responsible for the general wiki administration (aka who has access to the actual WikiMedia installation)? ED?
 
Last edited by a moderator:
I'll take a look later as I'm on phone too much ltely while kid naps :)

also recall nothing is set in stone and things Are always chNging, and we've thought about a million usage scenarios and rriefd to hit the sweet spot.. But you can't please everyone :) still you can always unpack like Ed says :)

jeffphone
 
My opinion, it's going to rock. No doubt it will be built on after release, or supplemented by PND management utilities. But even as it stands, it's more friendly and efficient than anything that has appeared on an open handheld. Or a desktop computer, arguably, but I'm not feeling arguable so let's not go there.
 
Gruso said:
My opinion, it's going to rock. No doubt it will be built on after release, or supplemented by PND management utilities. But even as it stands, it's more friendly and efficient than anything that has appeared on an open handheld. Or a desktop computer, arguably, but I'm not feeling arguable so let's not go there.
Friendly, yes. Efficient, no way! It's fast enough for nobody to notice, but it would be possible to speed up the discovery and PND access stuff by at least a factor of 3. The reason why it hasn't been sped up by that factor is probably that nobody wants to do the needed bit-twiddling (e.g. BASH scripts are being used and the format requires massive amounts of fscan() to find metadata so yeah it's *slow*, relatively speaking).
 
Last edited by a moderator:
See, I changed my wording twice before posting that and I knew that would happen anyway :D I don't mean efficient under the hood, I'm not qualified to go there. :) I just mean in the end user sense. Perhaps I should have left it at "friendly."
 
We can make appdata location configurable .. Post release :)

I don't think conf files should be in the FAQ.. Few will need to look, and it's too low level for most people

a few errors but pretty good :)

jeffphone
 
I think the PND system is a fabulous idea and I'm excited about how much effort has gone into making it "right." It reminds me very much of the system around Rox-Filer which never got, I thought, the attention it deserved.

In a sense, the PND is amusing because it's a step back to the days of DOS (TOS, etc.) and the self-contained .exe one could copy & run without worrying about installation or dependencies. Remember dreaming of a 20M hard disk? Or note how a full Ubuntu installation still clocks in around 4Gb or so? Now a pair of 8Gb cards is pretty ho-hum. Self-contained (even if occasionally partially redundant) application bundles that are easy to swap around, remove, upgrade, etc., sound perfect.
 
I like the PND system as it stands.

As for a "PND Manager" I wonder if it would be feasible to integrate PNDs with a more traditional package management system. Something along the lines of PND repositories that behave similar to a deb repository in Ubuntu, but with the default install locations for PNDs being the SD card and for PND settings being appdata.

It would be nice to be able to type

Code:
sudo apt-get update
sudo apt-get upgrade

Or click reload, mark upgrades, apply in a GUI and it would upgrade all software, both those installed in traditional Linux-style to the NAND and the PNDs on the SD Card. Naturally, such a system would also feature the option to remove(delete the PND) or purge(delete PND and associated appdata) and orphaned appdata would ideally show up under the "residual config" status.

Games that cannot be distributed in a complete, self-contained format could be put in the "Multiverse" section of such repositories.

Honestly, I would think a PND manager useful only if it allowed me to manipulate PND-packaged software similar to how apt-get and synaptic let me manipulate deb-packaged software on my PC.
 
I have a question.
What does to the file structure look like to the program being run?
Dose it look like everything (the data contained in the PND and the appdata folder) is in the current cwd, only when you try to write to the cwd, it writes to the appdata?
If so, how are duplicates handled?
 
Dimacus said:
Dose it look like everything (the data contained in the PND and the appdata folder) is in the current cwd, only when you try to write to the cwd, it writes to the appdata?
Yes.
Dimacus said:
If so, how are duplicates handled?
Which duplicates? You mean, what happens when the app writes to a file that already exists? It depends on which unionfs is being used; I think that aufs will copy the file from the PND to the appdata folder and then make the changes to the copied file.
 
Last edited by a moderator:
When a .pndfile or PXML.xml dir get mounted, any writes back to the mounted area are put into appdata, with a subdir by the unique-id. i.e.: With the hypothetical MAME.pnd, it might update its config files after a user changes something, or create new files, or store hiscores or whatever. If it doesn't write them to NAND, and doesn't want ot write them to /mame/some/dir, but instead record it to itself for whatever reason, it would go to /pandora/appdata/MAMEs-ID/ instead. The pnd or PXML.xml app area is never modified during a run, only the appdata. (But when an application reads its own path, it will pick up the appdata version of the file instead of the actual file. Then magic of union-type filesystems!)

From: http://pandorawiki.o...#SD_card_layout :)

[edit] ninja'd
 
dflemstr said:
Which duplicates? You mean, what happens when the app writes to a file that already exists? It depends on which unionfs is being used; I think that aufs will copy the file from the PND to the appdata folder and then make the changes to the copied file.

And I take it that the next time the app is launched, the file in appdata is the one presented when reading the cwd. (This might be stupid to ask, but just to be sure :) )
 
Last edited by a moderator:
Back
Top