水木社区手机版
- 主题:请教一个ofstream的flush问题
- 讲真，这个水平，你们公司是认真的嘛？
文件系统的内部操作对使用者是透明的，这是基本原则，如果一个process close的句柄，另外一个process不能打开的话，要么是你的程序出错了，要么是你用的文件系统的API有问题，可能是异步api之类，这种情况你需要去读文件系统api的文档。但是总之，和文件系统没有关系
【 在 fishingriver 的大作中提到: 】
: 多谢回复，这样的话，就是说只要我写完，他就可以读了。
: 我之前没把我的应用讲清楚，是这样的：
: （1）对方并不在本地开打和读写我的文件，他会用把我写好的文件传到服务器上。这种情况，是不是我也可以在我close之后，立刻通知他，他就可以立刻上传了？
: ...................
--
FROM 115.199.99.* - 【 在 fishingriver 的大作中提到: 】
: 多谢回复，这样的话，就是说只要我写完，他就可以读了。
: 我之前没把我的应用讲清楚，是这样的：
: （1）对方并不在本地开打和读写我的文件，他会用把我写好的文件传到服务器上。这种情况，是不是我也可以在我close之后，立刻通知他，他就可以立刻上传了？
他不在本地打开读，怎么上传？
: （2）他上传我产生的数据，是不是也得先把数据弄到缓存里才能上传，而我写的数据已经在缓存里了，这个缓存对于我的程序和他的程序都是透明可以访问的，所以我一close，他就可以上传了？
只要机器不掉电，缓存就是透明的，不用关心。不过还是建议你去研究一下操作系统的文件系统部分
: （3）我有的时候需要写好几个文件，然后再通知他。我发现有时我写完最后一个文件都close了，但之前还有几个文件，名字都没出现在硬盘上。得过一阵子文件才会开始出现在硬盘上。这种情况我也可以写完最后一个文件并且close之后（这时还有几个文件没出现在硬盘上），就可以通知
: 他了吗？
肯定是你的程序bug了
--
FROM 106.38.162.* - 还在实习阶段
【 在 ziqin 的大作中提到: 】
: 讲真，这个水平，你们公司是认真的嘛？
: 文件系统的内部操作对使用者是透明的，这是基本原则，如果一个process close的句柄，另外一个process不能打开的话，要么是你的程序出错了，要么是你用的文件系统的API有问题，可能是异步api之类，这种情况你需要去读文件系统api的文档。但是总之，和文件系统没有关系
:
--
FROM 218.249.50.* - （1）他如果在上传前想把我生成的几个文件打包压缩一下，不是直接上传，是不是打包操作也得先读我的文件？
: 肯定是你的程序bug了
（2）这块好像不是bug，我的几个文件，比如文件1到文件6，都能生成，但最后一个写完close之后，不是每个文件名都立刻出现在硬盘上，但最后经过若干时间之后，还是会出现在硬盘上的。
（3）对于写文本文件而言，ofstream是不是比较慢的，有明显更快的方式吗？
【 在 jimmycmh 的大作中提到: 】
: 他不在本地打开读，怎么上传？
: 只要机器不掉电，缓存就是透明的，不用关心。不过还是建议你去研究一下操作系统的文件系统部分
: 肯定是你的程序bug了
--
FROM 223.104.40.* - 1 挫一点，close后，判断FileExist后，自己压缩，再通知对方压缩包的名字。
2 先创建一个空文件a.txt，每次复制过来成为新名字a1a2a3...，再打开写。
3 暂时不考虑速度吧。先把创建、写入、压缩、判存在、通知搞鲁棒了吧。你们直接上传文件，估计也不是啥高性能实时系统。
【 在 fishingriver 的大作中提到: 】
: （1）他如果在上传前想把我生成的几个文件打包压缩一下，不是直接上传，是不是打包操作也得先读我的文件？
: （2）这块好像不是bug，我的几个文件，比如文件1到文件6，都能生成，但最后一个写完close之后，不是每个文件名都立刻出现在硬盘上，但最后经过若干时间之后，还是会出现在硬盘上的。
: （3）对于写文本文件而言，ofstream是不是比较慢的，有明显更快的方式吗？
: ...................
--
FROM 61.185.187.* - 【 在 fishingriver 的大作中提到: 】
: （1）他如果在上传前想把我生成的几个文件打包压缩一下，不是直接上传，是不是打包操作也得先读我的文件？
当然，不读怎么打包？
: （2）这块好像不是bug，我的几个文件，比如文件1到文件6，都能生成，但最后一个写完close之后，不是每个文件名都立刻出现在硬盘上，但最后经过若干时间之后，还是会出现在硬盘上的。
没听说过有这样的事情，创建成功就能看到。你写个最简单的程序，就创建几个文件写验证一下。
: （3）对于写文本文件而言，ofstream是不是比较慢的，有明显更快的方式吗？
不慢
--
FROM 106.38.162.* - 我也碰到过这种问题。
大概两个进程在不同的机器上，都挂载nfs。
然后A进程写入数据文件，close()后通知另一个机器上的B进程。
B进程开始按格式读取。
经常segfault，因为nfs lag，发ticket给公司IT说nfs设置有问题。
人家表示我们不应该assume文件同步，拒绝帮助。
最后解决方法是，A进程写完文件后算个md5sum传给B进程。
B进程开始读文件之前死循环算文件md5sum，匹配了再开始parse文件。
【 在 fishingriver 的大作中提到: 】
: 多谢回复，这样的话，就是说只要我写完，他就可以读了。
: 我之前没把我的应用讲清楚，是这样的：
: （1）对方并不在本地开打和读写我的文件，他会用把我写好的文件传到服务器上。这
: 种情况，是不是我也可以在我close之后，立刻通知他，他就可以立刻上传了？
: ...................
--
FROM 158.140.1.*