Comment puis-je utiliser Delphi pour tester si un répertoire est écrit?

@Andreas Voir mon édition - si je pouvais remplacer cette fonction par un appel d'une fonction de bibliothèque existante (peut-être même avec un support multiplateform), cela serait certainement une amélioration.

Je ne peux pas vraiment voir quoi que ce soit, ce n'est pas dans la RTL - qui est l'appel JCL?

@ Demark Code est inspiré par Filecreatetemp dans l'unité JCLILEUSTILS, mais uniquement la partie Mswindows.

Je n'ai jamais été fan de fonctions comme celle-ci. Qu'est-ce que vous allez faire en fonction de la répertoire ou non du répertoire? Pourquoi n'essayez-vous pas de le faire, et s'il échoue, manipulez-la gracieusement.

@Luke non tous les utilisateurs ont des privilèges d'administration, mais l'application doit écrire dans ce répertoire - devinez maintenant que cette application fera si la fonction renvoie false :)

Que doivent faire les privilèges administratifs avec quoi que ce soit, @MJustin? Cette fonction ne compte pas du tout. Voulez-vous ça? Quelle différence cela ferait-il? Notez que, simplement parce que vous pouvez créer de nouveaux fichiers ne signifie pas que vous pouvez modifier (ou supprimer) fichiers existants. Ou, vous serez peut-être autorisé à modifier des fichiers, mais ne créez pas de nouveaux. Assurez-vous de tester les actions que vous voulez vraiment faire.

Mon point est qu'il n'y a pas vraiment besoin de fonctions génériques comme celle-ci. Au lieu de cela, essayez simplement d'essayer d'écrire tous les fichiers dont vous avez besoin, et si quelque chose échoue, faites ce que vous feriez si cette fonction est renvoyée fausse. Par exemple, si les fichiers que vous devez écrire sont bloqués par un autre processus? Cette fonction ne va pas attraper des choses comme ça.

@Luke: Lorsqu'un créateur échoue, il peut être utile de loger des informations supplémentaires sur l'environnement. Une partie de cela pourrait être de savoir si le dossier de destination a été trouvé et écrit. Une autre partie pourrait être (quelque chose que nous faisons régulièrement dans nos journaux) pour répertorier tous les processus ayant des poignées dans le fichier que nous ne pouvons pas accéder ... Cette fonction a donc son mérite de soi. En outre, nous l'utilisons souvent après l'échec de l'écriture de détection d'un dossier en lecture seule et tenter de la modifier à un écrinable afin que nous puissions réessayer l'écriture. Oui, nous pourrions aveuglément essayer de le rendre écritable, mais nos journaux sont maintenant beaucoup plus informatifs.

@Marjan Vous avez frappé la tache, par exemple, il est utile pour les chèques de la configuration d'environnement correcte dans une configuration multi-utilisateurs / TerminalServer / FileServer.

@Luke: Voici un scénario possible. Une application pouvant être utilisée comme "portable", c'est-à-dire d'un lecteur amovible. La première chose que je voudrais faire est de vérifier si je peux écrire des données et une configuration modifiées. Si, pour une raison quelconque, je suis à partir d'un CD-ROM, disons ou une pendrive protégée en écriture, je définirais un drapeau pour éviter toute tentative d'opérations d'écriture, car dans ce cas, ce n'est pas une erreur ou une cause de préoccupation . Sinon, l'utilisateur pourrait être soumis à beaucoup d'erreurs d'erreur «accès refusé» et être ennuyé à juste titre.

Ce sont deux choses différentes; Ce n'est pas parce qu'un répertoire n'est pas inscriptible (comme déterminé par le code donné dans la question) ne signifie pas qu'il réside sur un support en lecture seule. L'utilisation de code comme celle-ci est probablement suffisamment bonne pour une utilisation pratique, mais si votre programme est largement utilisé, vous passerez dans des cas de bord.