Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Uma área de especial preocupação para os sistemas de arquivos é o tratamento adequado das operações de renomeação. Uma área semelhante de preocupação é a criação de links físicos para sistemas de arquivos que suportam links físicos. Para operações de renomeação, é possível que um sistema de arquivos exclua um arquivo (o destino da operação de renomeação), o que requer verificações de segurança adicionais pelo sistema de arquivos.
Ao examinar a estrutura de controlo para uma operação de renomeação, um dos campos da 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 controlo da operação de link rígido, um dos campos da 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 alvo da operação, se ele existir. Embora o sistema de arquivos FASTFAT não suporte links físicos, ele suporta operações de renomeação. Essas semântica e comportamento podem ser vistos dentro do código-fonte do sistema de ficheiros FASTFAT na função FatSetRenameInfo (consulte o ficheiro 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), essa verificação também exigiria verificação de segurança para garantir que o chamador tivesse permissão para excluir o arquivo determinado (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;
}