Créer unique nom de fichier de commandes Windows

J'ai vu de nombreux posts sur la création d'un nom de fichier unique à partir de la naïveté %TEMPS% à l'plausible (mais insuffisante) %RANDOM%. À l'aide de wmic os get localdatetime est beaucoup mieux, mais il peut encore échouer sur plusieurs CPU/core machines. Le script suivant va finalement échouer lorsque vous exécutez en 5+ coques sur un multiple de base de la machine.

@ECHO OFF
SETLOCAL ENABLEDELAYEDEXPANSION

FOR /L %%i IN (0, 1, 1000) DO (
    FOR /F "usebackq" %%x IN (`wmic os get localdatetime ^| find "."`) do (set MYDATE=%%x)
    ECHO MYDATE is now !MYDATE!
    IF EXIST testuniq_!MYDATE!.txt (
        ECHO FAILED ON !MYDATE!
        GOTO TheEnd
    )
    COPY NUL >testuniq_!MYDATE!.txt
)

:TheEnd
EXIT /B 0

Quelqu'un aurait-il un moyen fiable pour créer un nom de fichier unique dans un script shell?

Ce n'est pas souvent nous poser une question au lot-fichier les terres que les bons de souscription de plus de 5 réponses. +1 question intéressante!

InformationsquelleAutor lit | 2015-01-06

10

Tout système qui s'appuie sur un nombre aléatoire peut théoriquement échouer, même à l'aide d'un GUID. Mais le monde semble avoir accepté que les Guid sont assez bonnes. J'ai vu du code posté quelque part qui utilise CSCRIPT JScript pour générer un GUID.

Il y a d'autres façons:

D'abord, je vais supposer que vous êtes en train de créer un fichier temporaire unique. Depuis le fichier sera supprimé une fois que votre processus se termine, tout ce que vous devez faire est d'établir un verrou exclusif sur une ressource dont le nom est un dérivé de votre temp de nom de fichier. (en réalité, j'en sens inverse - le temp le nom est dérivé de la ressource verrouillée nom).

Redirection établit un verrou exclusif sur le fichier de sortie, j'ai donc tout simplement dériver un nom dans le temps (avec de 0.01 seconde preciscion), et de tenter de verrouiller un fichier avec ce nom dans le dossier temp de l'utilisateur. Si cela échoue que je boucle en arrière et essayer à nouveau jusqu'à ce que je réussisse. Une fois que j'ai du succès, je suis assurée d'avoir la propriété exclusive de ce verrouillage, et tous les produits dérivés (à moins que quelqu'un intentionnellement rompt le système).

Une fois mon processus se termine, le verrou sera libéré, et un fichier temporaire avec le même nom peut être réutilisé plus tard. Mais le script normalement supprime les fichiers temporaires lors de la résiliation.
```
@echo off
setlocal

:getTemp
set "lockFile=%temp%\%~nx0_%time::=.%.lock"
set "tempFile=%lockFile%.temp"
9>&2 2>nul (2>&9 8>"%lockFile%" call :start %*) || goto :getTemp

:: Cleanup
2>nul del "%lockFile%" "%tempFile%"
exit /b


:start
:: Your code that needs the temp file goes here. This routine is called with the
:: original parameters that were passed to the script. I'll simply write some
:: data to the temp file and then TYPE the result.
>"%tempFile%" echo The unique tempfile for this process is "%tempfile%"
>>"%tempFile%" echo(%*
type "%tempFile%"
exit /b
```
Boucle en raison de la collision de nom doit être rare, sauf si vous êtes vraiment insister sur votre système. Si oui, vous pouvez réduire le risque de boucle par un facteur de 10 si vous utilisez WMIC OS GET LOCALDATETIME au lieu de %TIME%.

Si vous êtes à la recherche pour un unique et persistante de nom, alors le problème est un peu plus difficile, puisque vous ne pouvez pas maintenir le verrou indéfiniment. Pour ce cas, je vous recommande le WMIC OS LocalDateTime approche, couplé avec deux chèques pour les collisions de noms.

La première case permet simplement de vérifier que le fichier n'existe pas déjà. Mais c'est une condition de concurrence - deux processus pourraient faire le chèque en même temps. La deuxième case crée le fichier (vide) et établit un temporaire verrou exclusif sur elle. L'astuce est de s'assurer que le verrou est maintenu pour une période de temps plus longue que celle qu'il prend pour un autre processus pour vérifier si le fichier existe. Je suis paresseux, j'ai donc tout simplement utiliser DÉLAI d'établir une 1 seconde d'attente de façon plus que nécessaire.

L' :getUniqueFile routine attend trois arguments - un nom de base, une extension, et le nom de la variable où le résultat doit être stocké. Le nom de base peut inclure le lecteur et le chemin d'accès de l'information. Toutes les informations de chemin d'accès doit être valide, sinon la routine va entrer dans une boucle infinie. Ce problème pourrait être résolu.
```
@echo off
setlocal

:: Example usage
call :getUniqueFile "d:\test\myFile" ".txt" myFile
echo myFile="%myFile%"
exit /b

:getUniqueFile  baseName  extension  rtnVar
setlocal
:getUniqueFileLoop
for /f "skip=1" %%A in ('wmic os get localDateTime') do for %%B in (%%A) do set "rtn=%~1_%%B%~2"
if exist "%rtn%" (
  goto :getUniqueFileLoop
) else (
  2>nul >nul (9>"%rtn%" timeout /nobreak 1) || goto :getUniqueFileLoop
)
endlocal & set "%~3=%rtn%"
exit /b
```
Le dessus doit être garantie pour renvoyer un nouveau nom de fichier unique pour le chemin d'accès donné. Il y a beaucoup de place pour l'optimisation d'établir une commande à exécuter lors de la serrure vérifier que prend "assez longtemps", mais pas "trop long"
- Votre fichier de verrouillage idée semble être la plus infaillible de la solution. Forcer chaque instance d'établir un verrou exclusif garantit qu'aucune des deux instances simultanées sera jamais en mesure d'utiliser le même fichier. Il est immunisé aux conditions de course. Si j'étais l'O. P. ce serait de gagner.
- Je suis d'accord. Ce qui semble être la plus industrielle de la force de la solution.
- Je suis un réexamen de cette rubrique. Le problème, c'est que mon "Votre code" doit renvoyer un code de sortie. Si elle renvoie une valeur non nulle, les transferts de contrôle de la boucle pour obtenir un nom unique.
- Cela fonctionne bien pour moi. J'ai dû ajouter une ligne à supprimer les caractères d'espace parce que le format de l'HEURE peut être une horloge de 12 heures avec un espace. set "lockFile=%lockFile: =%
- Je ne vois aucune raison pourquoi vous ne pouvez pas avoir des espaces à l'intérieur de la serrure de nom de fichier (ailleurs que dans la fin). Mais il n'est certainement pas de mal à les supprimer.
- Vous avez raison que le fait d'avoir un espace dans le nom de fichier de verrouillage peuvent travailler. Cependant, la température d'application nom de fichier est interprété à partir de la serrure de nom de fichier. Qui serait ok pour contenir un espace, le FORUM tout le code qui utilise le nom de fichier temp variable est cité correctement. Parfois ce n'est pas le cas.
- J'ai trouvé un description de votre chemin de redirection, mais je serais heureux de comprendre ce 9> et 8> moyens. Désolé de vous déranger, mais peut-être que vous pouvez me pointer dans la bonne direction? Merci 🙂
- Je suis simplement une redirection vers inutilisés (indéfini) handles de fichiers 8 et 9 (à ce point, il est évident qu'ils deviennent défini).
- Mais il n'y a aucune garantie que %TEMP% ne doivent pas contenir d'espaces ou d'autres caractères posant problème. Donc le temp de nom de fichier chemin d'accès doit être correctement cité partout où il est utilisé.
InformationsquelleAutor dbenham
4

Le Lot-JScript hybride script ci-dessous utilise WSH l'ofs.GetTempName() méthode qui a été conçu justement à cet effet:
```
@if (@CodeSection == @Batch) @then

@echo off

for /F "delims=" %%a in ('cscript //nologo //E:JScript "%~F0"') do set "fileName=%%a"
echo Created file: "%fileName%"
goto :EOF

@end

var fso = new ActiveXObject("Scripting.FileSystemObject"), fileName;
do { fileName = fso.GetTempName(); } while ( fso.FileExists(fileName) );
fso.CreateTextFile(fileName).Close();
WScript.Echo(fileName);
```
- C'est très bon. Je vais probablement choisir ce que la réponse après quelques tests supplémentaires à l'intégration dans un projet plus vaste.
- Au début, je pensais que le nom généré par GetTempName() a été assuré d'être unique. Mais, sur la base de ma lecture de diverses sources non officielles, il semble que le retour de nom est tout simplement un nombre au hasard, sans véritable vérification qu'elle est unique. Je pense que vous feriez mieux de l'utilisation de JScript pour générer un GUID.
- Il n'a pas d'importance si GetTempName() générer un nom unique ou pas, parce supplémentaires FileExists(fileName) test de garantir que le fichier est unique. GetTempName() est juste une méthode plus simple à utiliser que la combinaison de hasard et de l'heure.
- Mais vous avez une condition de course. Deux processus pourraient faire le chèque avec le même nom dans le même temps, et les deux sera un succès et le retour des noms en double. (Peu probable, mais c'est possible)
- Re: utilisation de JScript pour générer un GUID, j'ai ajouté un simple powershell exemple déjà. Mais je dois dire que, bien qu'il me fait de la peine de poster 2 solutions, tout en recommandant de quelqu'un d'autre, je pense que dbenham de la solution est le plus à l'épreuve des balles. Putain ça.
InformationsquelleAutor Aacini
4

Vous pouvez utiliser certutil base64 encode %date% %time% avec un %random% graines comme ceci:
```
@echo off
setlocal

:: generate unique ID string
>"%temp%\~%~n0.%username%.a" echo %username%%date%%time%%random%
>NUL certutil -encode "%temp%\~%~n0.%username%.a" "%temp%\~%~n0.%username%.b"
for /f "usebackq EOL=- delims==" %%I in ("%temp%\~%~n0.%username%.b") do set "unique_id=%%I"
del "%temp%\~%~n0.%username%.a" "%temp%\~%~n0.%username%.b"

echo %unique_id%
```
Dans le cas où le même scénario est en cours d'exécution à partir du même répertoire par plusieurs utilisateurs, j'ai ajouté %username% pour les fichiers temp pour éviter de nouveaux conflits. Je suppose que vous pourriez remplacer %random% avec %username% pour le même effet. Alors vous feriez seulement obtenir un conflit si un seul utilisateur exécute le même bloc de code deux fois en même temps.

(Edit: ajouté %username% comme une semence pour l'unicité.)
- Va certutil toujours produire le même résultat il l'entrée de ce la même chose? Si oui, alors si le texte original, le %date%%time%%random%, n'est pas unique, d'encodage, il ne va pas les aider. Dans mon expérimentation, le texte original n'est pas toujours unique.
- Combien de fils sont susceptibles de courir dans la même centisecond par le même utilisateur? Vous pouvez ajouter %username% comme une graine. Ou si vous voulez augmenter le caractère aléatoire de %random%, puis set /a "rand = (%random% + 1) * (%random% + 1) * %random%" devrait résulter en un nombre entier aléatoire dans la pleine signé de 32 bits gamme de -2147483648 à 2147483647. (Parce que quand un certain nombre dépasse 32 bits, le cmd interprète roule pour les nombres négatifs.) Vrai qu'il y a un peu de pondération et cela ne se traduira pas par des dérivés de nombres premiers, mais vous êtes toujours obtenir plus de hasard, tout de même.
InformationsquelleAutor rojo
3
```
@echo off
:: generate a tempfilename in %1 (default TEMPFILE)
:loop
set /a y$$=%random%+100000
set y$$=temp%y$$:~1,2%.%y$$:~-3%
if exist "%temp%\%y$$%" goto loop
SET "y$$=%temp%\%y$$%"&copy nul "%temp%\%y$$%" >nul 2>NUL
:: y$$ now has full tempfile name
if "%1"=="" (set "tempfile=%y$$%") else (set "%1=%y$$%")
```
Voici un coupe-bas version de mon fichier temporaire générateur de créer un fichier nommé tempnn.nnn dans le %temp% répertoire.

Une fois tempnn.nnn a été créé, il est simple de créer comme beaucoup d'autres tempfiles que vous voulez pour le processus en ajoutant un suffixe à %y$$%, par exemple, %y$$%.a etc. Bien sûr, cela suppose que certains autres processus n'est pas au hasard créer des noms de fichiers sans l'aide de cette procédure.
- J'aime que votre méthode fait sacrément sûr que le fichier n'existe pas avec if exist et une boucle.
- Je crois qu'il y a deux problèmes ici. Tout d'abord, %random% est souvent pas le fruit du hasard. Deuxièmement, le délai entre le test (s'il existe) et l'ensemble (copie nul) laisse la possibilité de l'échec.
- La boucle sur le fichier existe bel et prend soin de la rndom-n'est pas aléatoire problème. Certes, il existe une possibilité théorique qu'un fichier peut apparaître entre le test et la copie, mais il n'y a aucun lot ne peut en traiter. Il ne peut pas créer puis de tester car il peut tuer un fichier valide créé par un autre processus, de sorte que nous nous retrouvons avec le test-et-méthode de création. La Limitation de la langue - et, sauf si vous pouvez garantir que votre processus n'est pas interrompu, une limitation de n'importe quelle langue.
- Je suis d'accord avec Paul. Voir ma réponse pour un infaillible moyen de "faire face à cela".
InformationsquelleAutor Magoo
2

J'aime Aacini du JScript solution hybride. Tant que nous sommes des emprunts à d'autres environnements d'exécution, comment au sujet de l'aide .NET Système.GUID avec PowerShell?
```
@echo off
setlocal

for /f "delims=" %%I in ('powershell -command "[string][guid]::NewGuid()"') do (
    set "unique_id=%%I"
)

echo %unique_id%
```
InformationsquelleAutor rojo
1

Il y A longtemps dans un galax..groupe de discussion appelé alt.ms-dos.lot, un intervenant a insisté sur le dépôt d'un QBASIC solution à chaque problème posé, enveloppé dans un lot coque et prétendant qu'il s'agit du lot, car elle n'est utilisée standard de Microsoft-logiciel fourni.

Après un long moment, il a été guéri de ses égarements, mais j'ai été gravement allergique aux méthodes hybrides depuis. Assurez-vous - si elle guérit le problème, blah,blah - et parfois, il est impossible d'échapper à ce cours (exécuter le lot silencieusement, par exemple). En dehors de cela, je ne veux vraiment pas thebother de l'apprentissage d'une nouvelle langue ou deux...c'est pour ça que je évitent *script de solutions. YMMV.

Soi - voici une autre approche...
```
@ECHO OFF
SETLOCAL
:rndtitle
SET "progtitle=My Batch File x%random%x"
TITLE "%progtitle%"
SET "underline="
SET "targetline="
FOR /f "delims=" %%a IN ('TASKLIST /v^|findstr /i /L /c:"======" /c:"%progtitle%"') DO (
 IF DEFINED underline (
  IF DEFINED targetline GOTO rndtitle
  SET "targetline=%%a"
 ) ELSE (SET "underline=%%a")
)

:: Here be a trap. The first column expands to fit the longest image name...
:pidloop
IF "%underline:~0,1%"=="=" SET "underline=%underline:~1%"&SET "targetline=%targetline:~1%"&GOTO pidloop
FOR /f %%a IN ("%targetline%") DO SET /a pid=%%a
ECHO %pid%

GOTO :EOF
```
Essentiellement, définir le titre pour quelque chose d'aléatoire. Notez que x%random%x est utilisé, et non pas simplement %random% de sorte qu'une recherche de "x123x" ne les détecte pas "x1234x".

Ensuite, obtenir une verbose tasklist, l'emplacement de la ligne d'en souligner l'intitulé et le titre. La première ligne retournée par findstr sera le souligner, la prochaine sera mis targetline et de toutes les autres retours indiquent que le titre n'est pas unique, afin de revenir, de le modifier et essayez à nouveau jusqu'à ce qu'elle est unique.

Enfin, obtenir l'ID de processus qui est dans la deuxième colonne, en notant que la première est inconnue largeur (donc pourquoi le soulignement est saisi.)

Résultat : ce processus de PID qui doit être unique et peut donc être utilisé comme base pour un unique fichier temporaire nom - construire dans un répertoire réservé pour la fin.
- Alors que je l'ai fait essayer à obtenir le PID avant, je n'étais jamais venu à une solution viable. Capture d'écran de la sortie de tasklist.exe annonce de travail. Mais, je pense que Powershell peut être plus facile et plus direct.
InformationsquelleAutor Magoo

Je voudrais vous présenter une autre méthode et de savoir s'il y a des trous de est-il. S'il vous plaît laissez-moi savoir. Merci.

C:>title my shell a80en333xyb

C:>type getppid.ps1
(Get-WmiObject -Class Win32_Process -Filter "processid='$pid'").ParentProcessId

C:>powershell getppid.ps1
2380

Ou, pour l'exécuter, sans créer un .ps1 fichier:

powershell -NoProfile -Command "(Get-WmiObject -Class Win32_Process -Filter "processid=`'$pid`'").ParentProcessId"

Afin de vérifier que la bonne tâche est trouvé, le titre est définie à une rare valeur et tasklist.exe est utilisé pour la recherche de la valeur retournée par getppid.ps1.

C:>tasklist /v | find "2380"
cmd.exe                       2380 RDP-Tcp#0                  7      8,124 K Running         PHSNT\pwatson                                           0:00:03 my shell a80en333xyb

InformationsquelleAutor lit

0

rendre le contenu du fichier d'un objet, utilisez le pointeur de la memaddress que la première partie de votre nom de fichier et un Rand() comme votre deuxième partie. l'adresse de la mémoire sera unique pour tous les objets, même avec plusieurs instances en cours d'exécution.
- De belles idées si j'ai été en utilisant un langage tel que le C/C++, Python, Perl, Java, etc. C'est un DOS/Windows fichier de commandes de script. Je peux écrire ces autres choses, mais en essayant de ne pas.
- Je ne vois pas comment cela pourrait être garantie unique s'il y a plusieurs machines à écrire à un périphérique partagé.
- si vous utilisez un script batch puis peut-être "le nom de la machine - ID de processus - Horodatage - nombre aléatoire" doit être suffisamment unique.
- Cela ne fonctionne que pour les fichiers temporaires, tant que la mémoire est réservée tout au long de la durée de vie du fichier temporaire. Vrai, aucun autre processus ne peut avoir que mem adresse à un point donné dans le temps, mais la même adresse peut être retourné à différents points dans le temps non apparentés de processus, conduisant à la collision de nom si le fichier est persistante (pas temporaire).
- vrai. OK pour être certain de l'unicité universelle à travers plusieurs machines, plusieurs processus par machine, en persistant des noms de fichiers, vous proably besoin d'aller: MachineName (ou mieux: GUID) /ProcessID/TimeStamp/InternalMEMaddress et vous pouvez coller un RAND() sur la fin si vous voulez, mais il serait probablement exagéré. Aussi, je suis sûr que vous allez toucher le max de nom de fichier de la taille sur les systèmes windows avec que.mais le fait de tronquer le memaddress à moins significat 8 chiffres devraient suffire à côté de l'heure et le PID/UID sauf si vos fichiers sont très gros et la production de centaines par seconde.
InformationsquelleAutor Bryan Devaney

Vous devez vous connecter pour publier un commentaire.