DropBox pourrait-il interférer avec DeleteFile () / rename ()

J’ai eu le code suivant qui a été exécuté toutes les deux minutes toute la journée:

int sucessfully_deleted = DeleteFile(dest_filename); if (!sucessfully_deleted) { // this never happens } rename(source_filename,dest_filename); 

Une fois toutes les plusieurs heures, rename () échouerait avec errno = 13 (EACCES). Les fichiers impliqués étaient tous dans un répertoire DropBox et j’avais l’impression que DropBox pouvait en être la cause. J’ai pensé qu’il était peut-être possible que la fonction DeleteFile () renvoie avec une suppression différente de zéro, mais en réalité, DropBox pourrait encore être occupé à effectuer certaines tâches relatives à la suppression qui empêchent rename () de réussir. Ce que je fis ensuite fut de changer rename () en my_rename (), qui tenterait un rename () et en cas d’échec, Sleep () pendant une seconde et une seconde fois. Bien sûr, cela a parfaitement fonctionné depuis. De plus, je reçois un message de diagnostic indiquant les échecs de première tentative toutes les quelques heures. Il n’a jamais échoué à la deuxième tentative.

Donc, vous pourriez dire que le problème est entièrement résolu … mais j’aimerais comprendre ce qui pourrait se passer afin de mieux me défendre contre tout problème connexe lié à DropBox à l’avenir …

Vraiment, j’aimerais avoir une nouvelle fonction super_delete () qui ne retourne pas avant que le fichier ne soit correctement supprimé et terminé à tous égards.

sous Windows demande de supprimer le fichier vraiment jamais supprimer le fichier juste. il le marque FCB ( File Control Block ) avec un drapeau spécial ( FCB_STATE_DELETE_ON_CLOSE ). la suppression réelle ne se produira que lorsque le dernier descripteur de fichier sera fermé.

La fonction DeleteFile marque un fichier à supprimer à la fermeture. Par conséquent, la suppression du fichier ne se produit pas tant que le dernier descripteur du fichier n’est pas fermé. Les appels suivants à CreateFile pour ouvrir le fichier échouent avec ERROR_ACCESS_DENIED .

également si section existante (fichier mappé en mémoire) ouvert sur le fichier – le fichier même ne peut pas être marqué pour suppression. L’appel de l’API échoue avec STATUS_CANNOT_DELETE . donc en général impossible toujours supprimer le fichier.

dans le cas où il existe un autre descripteur ouvert pour le fichier (mais pas la section!) commence à partir de Windows 10 rs1 existe, nouveau fonctionnel pour la suppression – FileDispositionInformationEx avec FILE_DISPOSITION_POSIX_SEMANTICS . dans ce cas:

Normalement, un fichier marqué pour suppression n’est réellement supprimé que lorsque tous les descripteurs ouverts du fichier ont été fermés et que le nombre de liens pour le fichier est égal à zéro. Lorsque vous marquez la suppression d’un fichier à l’aide de FILE_DISPOSITION_POSIX_SEMANTICS , le lien est supprimé de l’espace de noms visible dès que le descripteur de suppression POSIX a été fermé, mais les stream de données du fichier restnt accessibles aux autres descripteurs existants jusqu’à la fermeture du dernier descripteur.

 ULONG DeletePosix(PCWSTR lpFileName) { HANDLE hFile = CreateFileW(lpFileName, DELETE, FILE_SHARE_VALID_FLAGS, 0, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS|FILE_FLAG_OPEN_REPARSE_POINT, 0); if (hFile == INVALID_HANDLE_VALUE) { return GetLastError(); } static FILE_DISPOSITION_INFO_EX fdi = { FILE_DISPOSITION_DELETE| FILE_DISPOSITION_POSIX_SEMANTICS }; ULONG dwError = SetFileInformationByHandle(hFile, FileDispositionInfoEx, &fdi, sizeof(fdi)) ? NOERROR : GetLastError(); // win10 rs1: file removed from parent folder here CloseHandle(hFile); return dwError; } 

Mettre à jour

Désolé, je n’ai pas bien compris la question la première fois. Je pensais que DeleteFile avait renvoyé l’erreur 13.

Je comprends maintenant que DeleteFile réussit mais que le changement de nom échoue immédiatement après. Il pourrait s’agir simplement d’un problème de synchronisation avec le système de fichiers. Après avoir appelé DeleteFile, le fichier sera supprimé lorsque le système d’exploitation valide les modifications apscopes au système de fichiers. Cela peut ne pas apparaître immédiatement. Si vous devez effectuer plusieurs opérations sur le même chemin, consultez les transactions https://docs.microsoft.com/it-it/windows/desktop/api/winbase/nf-winbase-deletefiletransacteda .

– ANCIENNE REPONSE –

C’est correct. Si une autre application gère ce fichier, DeleteFile échouera. Citation de documents MSDN https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-deletefile :

The DeleteFile function fails if an application attempts to delete a file that has other handles open for normal I/O or as a memory-mapped file (FILE_SHARE_DELETE must have been specified when other handles were opened).

Ceci s’applique à Dropbox, à l’antivirus ou, en général, à toute autre application susceptible d’ouvrir ces fichiers. Dropbox peut ouvrir le fichier pour calculer son hachage (pour rechercher des modifications) à tout moment. Même chose avec l’antivirus.