- 17 Jul, 2012 1 commit
-
-
Nikolay Sivov authored
-
- 16 Jul, 2012 1 commit
-
-
Nikolay Sivov authored
-
- 13 Jul, 2012 2 commits
-
-
Nikolay Sivov authored
-
Nikolay Sivov authored
-
- 25 Apr, 2011 1 commit
-
-
Marcus Meissner authored
-
- 23 Nov, 2010 1 commit
-
-
David Hedberg authored
Truncating a large stream to less than 0x1000 bytes would cause an unnecessarily expensive conversion.
-
- 16 Nov, 2010 1 commit
-
-
Vincent Povirk authored
-
- 04 Nov, 2010 1 commit
-
-
Vincent Povirk authored
-
- 26 Aug, 2010 1 commit
-
-
Vincent Povirk authored
-
- 19 Jul, 2010 5 commits
-
-
Vincent Povirk authored
Some ILockBytes objects will not really write changes until their Flush method is called. Also, further optimizations to the storage implementation will involve caching writes, which will have to be flushed at times.
-
Vincent Povirk authored
-
Vincent Povirk authored
-
Vincent Povirk authored
-
Vincent Povirk authored
These fields are needed for the MS storage implementation to load files that were created by Wine with a block size of 4096.
-
- 06 May, 2010 1 commit
-
-
Vincent Povirk authored
-
- 05 May, 2010 1 commit
-
-
Vincent Povirk authored
A big block chain is a linked list, and we pretty much need random access to them. This should theoretically make accessing a random point in the chain O(log2 n) instead of O(n) (with disk access scaling based on the size of the read/write, not its location). It theoretically takes O(n) memory based on the size, but it can do better if the chain isn't very fragmented (which I believe will generally be the case for long chains). It also involves fetching all the big block locations when we open the chain, but we already do that anyway (and it should be faster to read it all in one go than piecemeal).
-
- 13 Apr, 2010 1 commit
-
-
Vincent Povirk authored
-
- 22 Mar, 2010 2 commits
-
-
Vincent Povirk authored
This value is stored in the storage file header. We currently hard-code it to 0x1000. I don't expect to see files in the wild with other values, but according to MS this is a valid configuration. For now, just fail if we see another value. I've also upgraded the message for unexpected values in storage file headers to a fixme, since they are valid according to MS.
-
Vincent Povirk authored
This makes creating small block chains O(n) instead of O(n**2) because we don't have to keep rechecking the first blocks in the file.
-
- 15 Mar, 2010 4 commits
-
-
Vincent Povirk authored
We can't determine the correct block size until we read the header, and we can't create the BigBlockFile until we know the correct block size. To solve this dilemma, have StorageImpl calculate the file size it needs instead of asking the BigBlockFile to "ensure a big block exists".
-
Vincent Povirk authored
This should always be calculated based on the big block size.
-
Vincent Povirk authored
Big block sizes can be 512 or 4096, so we define arrays that are large enough in either case.
-
Vincent Povirk authored
The header is always 512 bytes, regardless of the big block size.
-
- 16 Dec, 2009 1 commit
-
-
Vincent Povirk authored
-
- 11 Dec, 2009 2 commits
-
-
Vincent Povirk authored
TransactedSnapshotImpl acts as a proxy between the user and the storage interfaces that modify the file directly (or another transacted storage). Currently, it does not change the operations.
-
Vincent Povirk authored
-
- 10 Dec, 2009 1 commit
-
-
Vincent Povirk authored
-
- 09 Dec, 2009 4 commits
-
-
Vincent Povirk authored
-
Vincent Povirk authored
We can't do this safely when there are multiple objects for a single stream.
-
Vincent Povirk authored
-
Vincent Povirk authored
-
- 08 Dec, 2009 3 commits
-
-
Vincent Povirk authored
-
Vincent Povirk authored
-
Vincent Povirk authored
The maximum size of the name returned by Stat() on a top-level storage has nothing to do with DIRENTRY_NAME_BUFFER_LEN. Windows can return longer names and probably has a limit of MAX_PATH. Also, Stat always returns an absolute pathname, so we don't need a special case in StgOpenStorage.
-
- 07 Dec, 2009 5 commits
-
-
Vincent Povirk authored
-
Vincent Povirk authored
-
Vincent Povirk authored
-
Vincent Povirk authored
-
Vincent Povirk authored
-
- 04 Dec, 2009 1 commit
-
-
Vincent Povirk authored
-