问题标签 [filestream]

我显然已经养成了一个不好的编码习惯。这是我一直在编写的代码示例：

我认为这是因为该using子句明确调用Close()and Dispose()on theStreamReader也FileStream将被关闭。

我可以解决我遇到的问题的唯一方法是将上面的块更改为：

是否应该StreamReader通过在第一个区块中的处置来关闭底层证券FileStream？或者，我弄错了吗？

编辑

我决定发布实际有问题的代码块，看看我们是否能找到这个问题的根源。我现在只是好奇。

我以为我的using子句有问题，所以我将所有内容都扩展出来，但每次都无法复制。我在这个方法调用中创建了文件，所以我认为没有其他任何东西在文件上打开了句柄。我还验证了Path.Combine调用返回的字符串是否正确。

谁能看到这段代码有什么问题？

SIZE_BG 是 6MB，因为我正在尝试绘制一个大的位图图像 (3366x600)。我使用 malloc 来防止我的图像溢出堆栈。我在调用 glDrawPixels() 时遇到访问冲突错误。bgPtr 似乎指向正确的数据，因为我在调用 glDrawPixels 之前检查了前几个字节并且它们是正确的。

有没有一些有效的方法来获取“varbinary(max) filestream”列中的数据长度？我发现只有转换为 varchar 然后调用“LEN”函数的样本。

在我的本地 Windows XP 机器上，我无法再使用 FILESTREAM 创建数据库。

替代文字 http://img379.imageshack.us/img379/9899/errorv.jpg

此错误是由 MS 的以下安全更新之一引起的：

• KB952004
• KB923561
• KB961373
• KB956572
• KB959426
• KB960863

有人知道如何在不删除安全更新的情况下解决问题吗？

我正在开发一个教育领域的网站。我想Filestream在 SQL Server 2008 中使用二进制格式将文档（MS Word 或文本文件）存储在数据库中。但我无法在文本框中检索文档。

我的代码如下：

此代码仅适用于存储在文件系统而不是数据库中的文档。所以我尝试了以下代码：

在此代码中，它在线给出错误fs = File.OpenText(path); 为“拒绝访问路径”。

请帮忙！

我正在尝试将 xml 文件读入内存，添加一个节点，然后覆盖原始文件。

以下代码可以正常工作（它清除文件，然后将新字节写入顶部）：

但是，如果我在文件打开后尝试执行读取，则位置/截断调用不起作用：

有谁知道为什么这不起作用？

如果您检查流，在第一个代码中，在调用 truncate() 之后，bytesAvailable 属性将读取 0。但在第二个代码中，bytesAvailable 不会改变（它将显示当前文件大小）。

我正在为 C/C++ 库编写一个 .NET 适配器，其中方法“bar”采用常规 stdio FILE*。是否可以构建一个接口，以便托管代码用户可以传递托管（文件）流？那就是没有创建中间缓冲区和代码来管道之间的数据。还有 bar() 读取的假设是否会使事情变得更好？

我需要在给定目录中显示图像的缩略图。在将图像加载到图像组件之前，我使用 TFileStream 读取图像文件。然后将位图调整为缩略图大小，并分配给 TScrollBox 上的 TImage 组件。

它似乎工作正常，但是对于较大的图像会减慢很多。

有没有更快的方法从磁盘加载（图像）文件并调整它们的大小？

谢谢，彼得

I am attempting to use Filestream in sql server 2008 to store user uploaded images.

My problem is that NHibernate will not error, but it also will not save the data into the database. No record is created.

The Image class below is a custom class (not to be confused with System.Drawing.Image)

My method to save looks like this:

Maybe I'm saving wrong, maybe my mapping is off. ImageData is a varbinary(max) field in the database.

我在使用 FileStream.Write 函数时遇到了性能问题。

我有一个控制台应用程序，用于使用 StreamReader 对象从文件中读取 Base64 字符串（~ 大小为 400 KB）。我使用 Convert.FromBase64String 将此字符串转换为字节数组。然后我使用 FileStream 对象将此字节数组写入文件。这里得到的字节数组长度为 334991。

我测量了写入字节数组的时间——结果大约是0.116 秒。

只是为了好玩，我使用 ASCIIEncoding.GetBytes 函数从同一个 Base64 编码字符串中获取了字节数组（尽管我知道这不会给出正确的解码输出 - 我只是想尝试一下）。我使用 FileStream 对象将此字节数组写入文件。这里得到的字节数组长度为 458414。

我用这种方法测量了写入字节数组的时间——结果大约是0.008 秒。

这是示例代码：

我对大约 5000 个包含 Base64 编码字符串的文件进行了测试，写入这两种类型的字节数组所需的时间差几乎是 10 倍（使用 真实解码写入字节数组的时间更长）。

使用 Convert.FromBase64String 获得的字节数组的长度小于使用 ASCIIEncoding.GetBytes 函数获得的长度。

我想知道我要做的就是使用 FileStream 对象写入一堆字节。那么，为什么在将字节数组写入磁盘时会有如此巨大的性能差异（所需时间）？

还是我做错了什么？请指教。