获取文件的实际大小 [英] get the actual size of a file
问题描述
嗨
一般来说，
FileInfo fi = new FileInfo（path）;
long size = fi.Length;
以字节为单位获取文件的长度。但是，当复制文件时，即使复制操作仍在进行中，文件大小，如
Windows资源管理器中所示，或者使用上述两行代码导出，复制操作完成后，文件的大小将是
。有没有办法让b $ b获得写入硬盘的实际字节数，而副本
操作正在进行中？
我之所以要问的原因是我必须复制相当大的文件而我现在正在使用File.Copy（输入，输出）
来完成这项工作。对于进度
指示，我有一个线程通过
上述代码获得输出的大小。复制文件后，我附加了第二个
（二进制）文件，但在开始追加之前，我将
输出文件的长度设置为总数输出的长度。所以，我的进度
指标只有2个值，我的线程获取文件大小就像
那样不存在。
我可以想象的唯一方法就是转储File.Copy，手动创建一个新文件
，然后将二进制数据从输入复制到输出中。尺寸。除了额外的复杂性之外，这种机制与内置文件副本
机制相比还有继承性吗？b $ b性能劣势吗？我只是猜测这里，但我认为I / O缓冲区的大小可能会对性能有显着影响。
问候
Stephan
Hi
Generally,
FileInfo fi = new FileInfo(path);
long size = fi.Length;
gets you the length of a file in bytes. However, when copying files, even
while the copy operation is still in progress, the filesize, as indicated in
Windows Explorer or derived with the above two lines of code, will be the
size of the file once the copy operation has completed. Is there a way to
get the actual number of bytes written to the harddisk while a copy
operation is under way?
The reason I''m asking is that I have to copy rather large files and I''m
currently using File.Copy(input, output) to do this. For a progress
indication, I have a thread that gets the size of the output via the
abovementioned code. Once the file has been copied, I append a second
(binary) file, but prior to starting to append, I set the length of the
output file to the total length the output is going to have. So, my progress
indicator has 2 values only and my thread getting the filesize could just as
well not exist.
The only way around this I can imagine is dump File.Copy, create a new file
manually, and copy the binary data from input to output in chunks of a
certain size. Besides the additional complexity, is there any inheritent
performance disadvantage of such a mechanism versus the built-in file copy
mechanism? I''m just guessing here but I assume the size of I/O buffers could
have a noticeable effect on performance.
Regards
Stephan
推荐答案
你是绝对正确的。对于
的表现会有明显的影响。
Stephan Steiner < ST ***** @ isuisse.com>在消息中写道
新闻：OA ************** @ TK2MSFTNGP14.phx.gbl ...
You are absolutely correct. There will be a noticeable effect on
performance.
"Stephan Steiner" <st*****@isuisse.com> wrote in message
news:OA**************@TK2MSFTNGP14.phx.gbl...
嗨
一般来说，
FileInfo fi = new FileInfo（path）;
long size = fi.Length;
以字节为单位获取文件的长度。但是，在复制文件时，即使复制操作仍在进行中，文件大小，如Windows资源管理器中指示的那样，或者使用上面两行代码派生的，将是
大小复制操作完成后的文件。有没有办法在复制
操作过程中获得写入硬盘的实际字节数？
我问的原因是我有复制相当大的文件，我现在正在使用File.Copy（输入，输出）来执行此操作。对于进度
指示，我有一个线程通过上面提到的代码获得输出的大小。复制文件后，我追加第二个（二进制）文件，但在开始追加之前，我将
输出文件的长度设置为输出的总长度。所以，我的
进度指示器只有2个值，我的线程获取文件大小
也可能不存在。
我可以想象的唯一方法是转储文件。复制，手动创建一个新的
文件，并将二进制数据从输入复制到一定大小的块中。除了额外的复杂性之外，这种机制与内置文件复制机制相比还有任何继承性的缺点吗？我只是猜测这里，但我认为I / O缓冲区的大小可能会对性能产生明显的影响。
问候
Stephan
Hi
Generally,
FileInfo fi = new FileInfo(path);
long size = fi.Length;
gets you the length of a file in bytes. However, when copying files, even
while the copy operation is still in progress, the filesize, as indicated
in Windows Explorer or derived with the above two lines of code, will be
the size of the file once the copy operation has completed. Is there a way
to get the actual number of bytes written to the harddisk while a copy
operation is under way?
The reason I''m asking is that I have to copy rather large files and I''m
currently using File.Copy(input, output) to do this. For a progress
indication, I have a thread that gets the size of the output via the
abovementioned code. Once the file has been copied, I append a second
(binary) file, but prior to starting to append, I set the length of the
output file to the total length the output is going to have. So, my
progress indicator has 2 values only and my thread getting the filesize
could just as well not exist.
The only way around this I can imagine is dump File.Copy, create a new
file manually, and copy the binary data from input to output in chunks of
a certain size. Besides the additional complexity, is there any inheritent
performance disadvantage of such a mechanism versus the built-in file copy
mechanism? I''m just guessing here but I assume the size of I/O buffers
could have a noticeable effect on performance.
Regards
Stephan
Stephany Young< noone @ localhost>写道：
Stephany Young <noone@localhost> wrote:
你是绝对正确的。对于
性能会有明显的影响。
You are absolutely correct. There will be a noticeable effect on
performance.
嗯，根据
，性能会有明显的影响缓冲区大小。如果适当选择缓冲区大小为
，则File.Copy和复制chunk-by-chunk之间的性能不会有明显的影响。
-
Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet
如果回复该群组，请不要给我发邮件
Well, there will be a noticeable effect on performance depending on the
buffer size. There needn''t be a noticeable effect on performance
between File.Copy and copying chunk-by-chunk if the buffer size is
chosen appropriately.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
那么什么是合适的缓冲区大小？我需要复制一个文件
并附加另一个文件。第一个文件可以是从100 MB
到2 GB的任何位置，而要追加的文件更可能在10 - 100
MB区域内。 />
" Jon Skeet [C＃MVP]" < SK *** @ pobox.com>在消息中写道
新闻：MP ************************ @ msnews.microsoft.c om ...
So what would be a suitable buffer size? I need to make a copy of one file
and append another file to it. The first file can be anywhere from a 100 MB
to 2 GB, whereas the file to be appended will more likely be in the 10 - 100
MB area.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Stephany Young< noone @ localhost>写道：
Stephany Young <noone@localhost> wrote:
你是绝对正确的。对于
性能会有明显的影响。
You are absolutely correct. There will be a noticeable effect on
performance.
嗯，根据缓冲区大小，会对性能产生明显影响。如果适当选择缓冲区大小，则File.Copy与逐块复制之间的性能不会有明显的影响。
Well, there will be a noticeable effect on performance depending on the
buffer size. There needn''t be a noticeable effect on performance
between File.Copy and copying chunk-by-chunk if the buffer size is
chosen appropriately.
这篇关于获取文件的实际大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
