Hi, sp...@caiway.net wrote: > how does one force to refresh this memory with a command?
to...@tuxteam.de wrote: > What do you mean by "refresh"? What's in the cache is always > the "freshest" version: Indeed. With normal filesystem operations there should be no need to call something like sync(2) in order to get a consistent representation of the current filesystem state. That's actually the riddle of this thread: The filesystem behavior outside the script and the time stamps look like the file was created 30 seconds after the script began to open, write, and close the file. The file content indicates that it was written shortly after the script began. I understand that Vincent Lefevre suspects these discrepancies to be a bug in the ext4 driver. I rather suspect that ext4 is ok and that we observe the effects of some other glitch which caused the ext4 driver to create the finally observed file again, 30 seconds later. > nobody's writing to the disk behind the operating system's back > (unless they insist into getting into trouble). Burn programs do, because the kernel insists in being incapable of burning CD-R and other sequential media types or states. ioctl(SG_IO) performs SCSI transactions on the storage device by the kernel but without the higher level drivers being aware. E.g. you don't see the traffic counted in files of /proc and the block device driver will continue to show the medium state before the burn run. Remedy is to eject and reload the optical medium. On hard disks there would be ioctl(BLKRRPART). But for CDROM there is nothing comparable in Linux. Have a nice day :) Thomas
