enumeração CF_OPEN_FILE_FLAGS (cfapi.h)

  • Artigo

Sinaliza para solicitar várias permissões ao abrir um arquivo.

Syntax

typedef enum CF_OPEN_FILE_FLAGS {
  CF_OPEN_FILE_FLAG_NONE = 0x00000000,
  CF_OPEN_FILE_FLAG_EXCLUSIVE = 0x00000001,
  CF_OPEN_FILE_FLAG_WRITE_ACCESS = 0x00000002,
  CF_OPEN_FILE_FLAG_DELETE_ACCESS = 0x00000004,
  CF_OPEN_FILE_FLAG_FOREGROUND = 0x00000008
} ;

Constantes

 
CF_OPEN_FILE_FLAG_NONE
Valor: 0x00000000
Nenhum sinalizador de arquivo aberto.
CF_OPEN_FILE_FLAG_EXCLUSIVE
Valor: 0x00000001
Quando especificado, CfOpenFileWithOplock retorna um identificador de compartilhamento nenhum e solicita um RH (OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE) oplock no arquivo.

Uma chamada CreateFile normal que é aberta para qualquer um dos FILE_EXECUTE | FILE_READ_DATA | FILE_WRITE_DATA | FILE_APPEND_DATA | DELETE (ou ambos/ambos GENERIC_READ | GENERIC_WRITE) interromperá o oplock devido ao conflito de compartilhamento, conforme descrito na seção Comentários . O proprietário do oplock poderá concluir e reconhecer.
CF_OPEN_FILE_FLAG_WRITE_ACCESS
Valor: 0x00000002
Quando especificado, CfOpenFileWithOplock tenta abrir o arquivo ou diretório com acesso FILE_READ_DATA/FILE_LIST_DIRECTORY e FILE_WRITE_DATA/FILE_ADD_FILE; caso contrário, ele tentará abrir o arquivo ou diretório com FILE_READ_DATA/FILE_LIST_DIRECTORY.
CF_OPEN_FILE_FLAG_DELETE_ACCESS
Valor: 0x00000004
Quando especificado, CfOpenFileWithOplock tenta abrir o arquivo ou diretório com acesso DELETE; caso contrário, ele abre o arquivo normalmente.
CF_OPEN_FILE_FLAG_FOREGROUND
Valor: 0x00000008
Quando esse sinalizador é usado, CfOpenFileWithOplock não solicita um oplock. Isso deve ser usado quando o chamador está agindo como um aplicativo em primeiro plano. Ou seja, eles não se importam se o identificador de arquivo criado por essa API causa violações de compartilhamento para outros chamadores e eles não se importam em quebrar qualquer oplocks que já esteja no arquivo. Então, eles abrem o identificador sem solicitar um oplock.

Nota: O comportamento padrão em segundo plano solicita um oplock ao abrir o identificador de arquivo para que sua chamada falhe se já houver um oplock, e eles podem ser orientados a fechar o identificador se precisarem sair do caminho para evitar causar uma violação de compartilhamento mais tarde.
A menos que o chamador especifique CF_OPEN_FILE_FLAG_EXCLUSIVE para CfOpenFileWithOplock, o oplock obtido será apenas OPLOCK_LEVEL_CACHE_READ, não (OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE), portanto, não haverá a proteção contra violação de compartilhamento que um aplicativo em segundo plano normalmente deseja.

Comentários

Um aplicativo em segundo plano normalmente deseja operar de forma transparente em arquivos. Em particular, eles querem evitar causar violações de compartilhamento para outros abridores (em primeiro plano). Para fazer isso, eles pegam um (OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE) oplock, como seria concedido usando CF_OPEN_FILE_FLAG_EXCLUSIVE com CfOpenFileWithOplock. Em seguida, se algum outro abridor aparecer cujos modos de compartilhamento/acesso solicitados entram em conflito com o modo do aplicativo em segundo plano, o oplock do aplicativo em segundo plano será interrompido. Isso solicita que o aplicativo em segundo plano feche seu identificador de arquivo (para um identificador cf, o que faz com que ele se torne inválido – o identificador subjacente real foi fechado). Depois que o aplicativo em segundo plano fecha seu identificador, a outra solicitação para abrir continua sem encontrar a violação de compartilhamento. Tudo isso funciona devido à OPLOCK_LEVEL_CACHE_HANDLE parte do oplock. Sem CF_OPEN_FILE_FLAG_EXCLUSIVE, o oplock só tem OPLOCK_LEVEL_CACHE_READ proteção, portanto, a proteção contra violação de compartilhamento não é fornecida.

Quando CF_OPEN_FILE_FLAG_EXCLUSIVE não é especificado, o open é compartilhar tudo e obtém um OPLOCK_LEVEL_CACHE_READ oplock.

Uma chamada CreateFile normal não interromperá o oplock. Se o CreateFile normal especificar um modo de compartilhamento que está em conflito com o acesso do identificador cf (por exemplo, se o CreateFile normal não especificar FILE_SHARE_READ), o CreateFile normal falhará com ERROR_SHARING_VIOLATION. O oplock não é interrompido até que o outro chamador emita uma E/S conflitante, como uma gravação. Quando isso acontece , a interrupção do oplock é apenas consultoria.

Requisitos

Requisito Valor
Cliente mínimo com suporte Windows 10, versão 1709 [somente aplicativos da área de trabalho]
Servidor mínimo com suporte Windows Server 2016 [somente aplicativos da área de trabalho]
Cabeçalho cfapi.h

Confira também

CfOpenFileWithOplock

CreateFile