in reply to overwrite a file

I'm not familiar with the implementations of OS disk caching, but it seems to me there's no guarantee that any but the last call to overwrite_file makes it to disk from the system's cache. Even then... With a particularly good cache, absolutely nothing would be written to disk.

Remember, sys* disables user-land caching. It doesn't prevent OS caching. FILE_FLAG_NO_BUFFERING would do that in Windows, but I see no reference to it in win32/win32io.c in perl.git.

Replies are listed 'Best First'.
Re^2: overwrite a file
by varian (Chaplain) on Apr 26, 2007 at 06:19 UTC
    The approach is simple and granular. However I would agree with ikegami that system cache may work against you. In *nx systems you might consider to call sync after each file close call to have the system clean out its disk cache.

    For the really paranoid among us other things that may influence success are i.e. disk controller internal caches, cache issues with remote filesystems mounted over network, parallel read/writes on the file by another process. Besides those caching aspects you need to consider filesystem type, as your data may still live in the journal logs.

    Bottomline: Solid erasure of data on a granular level like files is always tricky.

      Bottomline: Solid erasure of data on a granular level like files is always tricky.
      Agreed. However, secure shredding on disk level is less tricky, albeit cumbersome, as seen here.
      --
      print map{chr}unpack(q{A3}x24,q{074117115116032097110111116104101114032080101114108032104097099107101114})
Re^2: overwrite a file
by jdporter (Paladin) on Jun 17, 2007 at 16:58 UTC
    sys* disables user-land caching. It doesn't prevent OS caching.

    Good point. In Windowsland, if the the device being written is a removable type (such as a USB drive), then one can simply disable disk write caching. This worked just fine for me.

    A word spoken in Mind will reach its own level, in the objective world, by its own weight