TitleLocation writeable on the 360?

Let's say I run some code like this on the 360:

string fullpath = Path.Combine( StorageContainer.TitleLocation, "new_file.dat" );
FileStream fs = File.Open( fullpath, FileMode.Create, FileAccess.Write );

Will this work on the 360 Or is "TItleLocation" read-only

Assuming this will work are there any FileMode operations that are off limits in TitleLocation or it's subdirectories

If this can be done, then is there any limit to the amount of space that can be written to TitleLocation or it's subdirectories other than the available free space on the 360 HD

Thanks - Ryan

Followup question...the XNA docs state that:

"The maximum size of an XNA project on an Xbox 360 is 2GB, so the entire game, including support files (level data, sound, etc) must not exceed that size."

Is this a limit in the transfer mechanism, or is this a physical limit of the TitleLocation folder and all of it's children

What I am curious about is if the game CAN in fact write to the TitleLocation as per my question above, will you be limited to 2GB total (including the binaries of the files that were pushed there), or is the 2GB check only done DURING the push of the content to the 360 from the PC (thereby limiting the game only to the size of the HD)

In other words, if on the 360 the game can write to TitleLocation, if when doing so it reaches a point where 2GB total is consumed, will an exception be thrown or will it just "work" and allow > 2GB to be stored (assuming there is room on the HD).

Thanks - Ryan

Yeah, my bet is it's a space limit in the 360 CF (essentially a quota mechanism), but I'm hoping I'm wrong. .;-) I really want access to the entire HD...

If the intention was to limit install size, it's possible that this was implemented in the transfer layer and not the CF layer. If it turns out that you can't write to the Title area on the 360, then the two would be functionally equivallent.

What I'm hoping is that:

1) your deployed game can write to the Title area on the 360

2) you can only transfer 2GB into the title area, but your game can write as much there as it wants to (until the HD is full)

I have to think some XNA MS dev knows the definitive answer to these...without having to write a test. <grin>

I'd gladly test this myself but right now my 360 is 2 hours away. ;-(

Ryan

Actually Jon you have to use the normal .Net file api's, but only after using the StorageContainer / StorageDevice. From the docs:

// Open a storage container
StorageContainer container =
device.OpenContainer( "StorageDemo" );

// Add the container path to our filename
string filename = Path.Combine( container.Path, "demobinary.sav" );

// Create a new file
if (!File.Exists( filename ))
{
FileStream file = File.Create( filename );
file.Close();
}
// Dispose the container, to commit the data
container.Dispose();

In fact, if all you are doing is reading in Title files, according to the docs you don't even need to mess around with StorageDevice. You can simply reference the path via StorageContainer.TitleLocation and then start using FIle, FileStream, etc on files in that path. THe "How to: Load a Game Data FIle" example in the docs does not even use a StorageDevice for this case. But I assume if you were writing to the TitleLocation you would need to, otherwise the File / FileStream etc would probably throw access exceptions. I haven't tried it for myself yet though but if I implemented it that's what I would have done. ;-)

- Ryan

So Shawn, you are positive that the "sandbox" allows full access (create, delete, truncate, overwrite, etc) to the Title location for your game

For example, if I wanted to I could transfer a resource highly compressed, and then during first run of the game decompress and write out a decompressed resource back to the TitleLocation so that future runs of the game will have that decompressed content cached. Doing this would clearly require the ability to create new files in the TitleLocation "sandbox".

Since I'm the kind of guy who likes to know how things work deep down...based on what you describe, and what the docs say, I'm guessing that the TitleLocation is always mounted during the lifetime of a game Whereas the "save" locations are fetched asynchronously and need to be opened via StorageDevice OpenContainer Here is the doc snippet I am referring to:

using System;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Storage;
using System.IO;

private static FileStream OpenTitleFile(
  string filename, FileMode mode, FileAccess access)
{
  string fullpath = Path.Combine( StorageContainer.TitleLocation, filename );
  return File.Open( fullpath, mode, access );
}

Every other Storage example explicitly shows a device.OpenContainer and container.Dispose. But not this one. Is this exampler perhabs assuming read-only access, and for read-only you do not need to open a container

My question is IF the TitleLocation is always open for the lifetime of the game, when do changes to the TitleLocation get persisted As I understand it, with the other Devices, it isn't until you DIspose of the container. But according to the above sample, we don't NEED a container to reference the TitleLocation.

I think this is one area where the docs could use some beefing up to explain what happening under the hood here.

Thanks - Ryan

Awesome Shawn, thanks, that is pretty much what I inferred from the docs and the sample. So in short StorageContainer.TitleLocation is "special".

I sure am hoping you are correct and the TitleLocation can be written to. That would be fantastic and it will allow for some really cool stuff. Especially if the 2GB limit can be avoided in the game I/O scenario (vs. PC-transfer scenario)...although I'm not holding my breath on that one. ;-)

I can't wait to play around with stuff this weekend when I get my 360 back.

Thanks - Ryan

Interesting idea; I hadn't thought of that. I'll have to mess around with that this weekend.

Incidenally, based on Shawn's statements above, I believe what I assumed below in bold is now incorrect:

"THe "How to: Load a Game Data FIle" example in the docs does not even use a StorageDevice for this case. But I assume if you were writing to the TitleLocation you would need to, otherwise the File / FileStream etc would probably throw access exceptions. I haven't tried it for myself yet though but if I implemented it that's what I would have done. ;-)"

It seems that whenever working with the TitleLocation, it is not necessary to do an OpenContainer and container.Dispose, even for writing.

- Ryan

ryan.rogers wrote:

What I am curious about is if the game CAN in fact write to the TitleLocation as per my question above, will you be limited to 2GB total (including the binaries of the files that were pushed there), or is the 2GB check only done DURING the push of the content to the 360 from the PC (thereby limiting the game only to the size of the HD)

You can, but you do not have access to the entire HDD. This restriction does not come from the transfer mechanism. Titles are stored in a single container, and that container can only grow to 2GB. Beyond that, you should expect exceptions indicating that the device is full. Think of the container with its files and subdirectories as something like a zip file. Although you access the container's contents like multiple files organized in folders, it is all really just one file. That file cannot store more than 2GB of data.

--Stephen