请教一个异常操作造成的CORE的问题

rocknio

程序处理流程：
      LINUX上一个多线程程序，其中一个线程在收到消息后在一个目录里将消息写入文件。第一次接到消息的时候FOPEN用a方式建立一个文件，每次收到消息用fseek将文件偏移量移到文件末，再写入
直到文件达到2M后，关闭文件，再建立一个文件，重复以上操作

     程序一直正常，今天一个人删除了我写文件的目录或文件（他不记得是在FTP工具中进入目录删除所有文件，还是直接删除的目录了），总之造成了程序coredump，我用GDB打开core文件，用where看到最后的stack是在fseek那句话上。

     后来我单独编写文件测试了一下，fopen打开以后，即使删除了文件，fseek也正常，fprintf也正常，只要不fclose，是不会core的。
     
     一时不知为何会coredump了

[ 本帖最后由 rocknio 于 2008-1-16 23:46 编辑 ]

cugb_cat

印象中fseek等调用的时候是操作内核中的数据,写入的时候也是先写入到内核缓冲区,你的测试程序在调用fclose之前不会core,我想可能因为fprintf只是把数据写入到内核缓冲区了,而掉fclose的时候才会真正的写入到文件中去.
至于你原来那个程序,因为一直在写文件,内核缓冲区在满了的时候也会把数据刷到文件中去,所以,会出现core.

lgfang

1, 用 'a' 打开文件，写的时候会自动添加在文件末尾，所以不用 fseek
2, 在unix系统上，删掉一个文件，其实只是unlink。只要有程序一直开着它，它就会一直存在。

所以你再找找别的原因吧

rocknio

在windows系统中如果某进程在操作一个文件，这个文件是无法被删除的
但是在linux，unix的文件系统机制下好像自己实现这一点比较麻烦
不知道有没有什么好办法解决在我open后，close前保证文件不被rm掉？

lgfang

原帖由 rocknio 于 2008-1-17 17:14 发表
在windows系统中如果某进程在操作一个文件，这个文件是无法被删除的
但是在linux，unix的文件系统机制下好像自己实现这一点比较麻烦
不知道有没有什么好办法解决在我open后，close前保证文件不被rm掉？

记录锁可以，但它是advisory的，也就是说必须所有进程都配合，去检查那个锁才行。
unix network programming vol2:IPC里讲到过。手头没书也可以 man fcntl 看里面的F_GETLK F_SETLK
或 man flock lockf

有的系统有强制锁，UNP v2 9.5 节提到：
the group-execute bit must be off, and
the set-group-id bit must be on

（但我在FreeBSD, linux 和Solaris上试了，好像都不行）

[ 本帖最后由 lgfang 于 2008-1-18 09:18 编辑 ]