Renomear e processamento de vínculo rígido
Uma área de preocupação específica para sistemas de arquivos é o tratamento adequado de operações de renomeação. Uma área de preocupação semelhante é a criação de link rígido para sistemas de arquivos que dão suporte a links rígidos. Para operações de renomeação, é possível que um sistema de arquivos exclua um arquivo (o destino da operação de renomeação), que requer verificações de segurança adicionais pelo sistema de arquivos.
Ao examinar a estrutura de controle para uma operação de renomeação, um dos campos de estrutura é a opção ReplaceIfExists :
typedef struct _FILE_RENAME_INFORMATION {
BOOLEAN ReplaceIfExists;
HANDLE RootDirectory;
ULONG FileNameLength;
WCHAR FileName[1];
} FILE_RENAME_INFORMATION, *PFILE_RENAME_INFORMATION;
Da mesma forma, na estrutura de controle da operação de link rígido, um dos campos de estrutura é a opção ReplaceIfExists :
typedef struct _FILE_LINK_INFORMATION {
BOOLEAN ReplaceIfExists;
HANDLE RootDirectory;
ULONG FileNameLength;
WCHAR FileName[1];
} FILE_LINK_INFORMATION, *PFILE_LINK_INFORMATION;
Em ambos os casos, a opção é substituir o destino da operação, se ela existir. Embora o sistema de arquivos FASTFAT não dê suporte a links rígidos, ele dá suporte a operações de renomeação. Essa semântica e o comportamento podem ser vistos no código-fonte do sistema de arquivos FASTFAT na função FatSetRenameInfo (consulte o arquivo de origem Fileinfo.c dos exemplos de fastfat que o WDK contém).
O exemplo de código a seguir para manipular uma operação de renomeação imita as verificações do sistema de arquivos para excluir o arquivo. Para um sistema de arquivos com um modelo de segurança mais robusto (NTFS, por exemplo), esse marcar também exigiria verificação de segurança para garantir que o chamador tivesse permissão para excluir o arquivo fornecido (o chamador tinha as permissões apropriadas necessárias para exclusão).
//
// The name already exists. Check if the user wants
// to overwrite the name and has access to do the overwrite.
// We cannot overwrite a directory.
//
if ((!ReplaceIfExists) ||
(FlagOn(TargetDirent->Attributes, FAT_DIRENT_ATTR_DIRECTORY)) ||
(FlagOn(TargetDirent->Attributes, FAT_DIRENT_ATTR_READ_ONLY))) {
try_return( Status = STATUS_OBJECT_NAME_COLLISION );
}
//
// Check that the file has no open user handles; otherwise,
// access will be denied. To do the check, search
// the list of FCBs opened under the parent Dcb, and make
// sure that none of the matching FCBs have a nonzero unclean count or
// outstanding image sections.
//
for (Links = TargetDcb->Specific.Dcb.ParentDcbQueue.Flink;
Links != &TargetDcb->Specific.Dcb.ParentDcbQueue; ) {
TempFcb = CONTAINING_RECORD( Links, FCB, ParentDcbLinks );
//
// Advance now. The image section flush may cause the final
// close, which will recursively happen underneath of us here.
// It would be unfortunate if we looked through free memory.
//
Links = Links->Flink;
if ((TempFcb->DirentOffsetWithinDirectory == TargetDirentOffset) &&
((TempFcb->UncleanCount != 0) ||
!MmFlushImageSection( &TempFcb->NonPaged->SectionObjectPointers,
MmFlushForDelete))) {
//
// If there are batch oplocks on this file, then break the
// oplocks before failing the rename.
//
Status = STATUS_ACCESS_DENIED;
if ((NodeType(TempFcb) == FAT_NTC_FCB) &&
FsRtlCurrentBatchOplock( &TempFcb->Specific.Fcb.Oplock )) {
//
// Do all of the cleanup now since the IrpContext
// could go away when this request is posted.
//
FatUnpinBcb( IrpContext, TargetDirentBcb );
Status = FsRtlCheckOplock( &TempFcb->Specific.Fcb.Oplock,
Irp,
IrpContext,
FatOplockComplete,
NULL );
if (Status != STATUS_PENDING) {
Status = STATUS_ACCESS_DENIED;
}
}
try_return( NOTHING );
}
}
//
// OK, this target is finished. Remember the Lfn offset.
//
TargetLfnOffset = TargetDirentOffset -
FAT_LFN_DIRENTS_NEEDED(&TargetLfn) * sizeof(DIRENT);
DeleteTarget = TRUE;
}