1. 21 Aug, 2002 2 commits
    • Anton Altaparmakov's avatar
    • Anton Altaparmakov's avatar
      NTFS: 2.1.0 - First steps towards write support: implement file overwrite. · c10104ad
      Anton Altaparmakov authored
      - Add configuration option for developmental write support with an
        appropriately scary configuration help text.
      - Initial implementation of fs/ntfs/aops.c::ntfs_writepage() and its
        helper fs/ntfs/aops.c::ntfs_write_block(). This enables mmap(2) based
        overwriting of existing files on ntfs. Note: Resident files are
        only written into memory, and not written out to disk at present, so
        avoid writing to files smaller than about 1kiB.
      - Initial implementation of fs/ntfs/aops.c::ntfs_prepare_write(), its
        helper fs/ntfs/aops.c::ntfs_prepare_nonresident_write() and their
        counterparts, fs/ntfs/aops.c::ntfs_commit_write(), and
        fs/ntfs/aops.c::ntfs_commit_nonresident_write(), respectively. Also,
        add generic_file_write() to the ntfs file operations (fs/ntfs/file.c).
        This enables write(2) based overwriting of existing files on ntfs.
        Note: As with mmap(2) based overwriting, resident files are only
        written into memory, and not written out to disk at present, so avoid
        writing to files smaller than about 1kiB.
      - Implement ->truncate (fs/ntfs/inode.c::ntfs_truncate()) and
        ->setattr() (fs/ntfs/inode.c::ntfs_setattr()) inode operations for
        files with the purpose of intercepting and aborting all i_size
        changes which we do not support yet. ntfs_truncate() actually only
        emits a warning message but AFAICS our interception of i_size changes
        elsewhere means ntfs_truncate() never gets called for i_size changes.
        It is only called from generic_file_write() when we fail in
        ntfs_prepare_{,nonresident_}write() in order to discard any
        instantiated buffers beyond i_size. Thus i_size is not actually
        changed so our warning message is enough. Unfortunately it is not
        possible to easily determine if i_size is being changed or not hence
        we just emit an appropriately worded error message.
      c10104ad
  2. 20 Aug, 2002 1 commit
  3. 17 Aug, 2002 1 commit
  4. 16 Aug, 2002 2 commits
  5. 17 Aug, 2002 1 commit
  6. 16 Aug, 2002 14 commits
  7. 17 Aug, 2002 6 commits
  8. 16 Aug, 2002 2 commits
  9. 15 Aug, 2002 11 commits