Windows bruger skjult fil i stedet for mappe i stier ... Hvorfor?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg (og min kollega) har dette problem med 32-bit applikationer på et 64-bit Windows 7 OS. Vi har også fundet de samme problemer, når vi påberåber en 64-bit applikation og sender en sti som beskrevet nedenfor som en parameter i cmd.exe.


På grund af stien 'C: \ dir1 \ dir2 \ file1.txt' har vi nogle 32-bit applikationer, der ikke synes at kunne konsekvent løse den pågældende sti og finde filen hvis der er en skjult fil af en bestemt navngivningsstruktur, der får det til at tabe det.


For eksempel, givet mappen/fil struktur:


dir1
    dir2
        file1.txt
    .dir2Blah


Det er vigtigt, at den 'skjulte' fils navn starter med de samme tegn som dem, der angiver en mappe på samme niveau af hierarkiet. Hvad der kommer efter, er i den skjulte fils navn irrelevant. Det kunne kaldes '.dir2Whatever'.


Problemet er, at det ofte ikke er (men ikke altid altid) nogle 32-bit applikationer, vi bruger, kan ikke finde filen1.txt-filen. Vi bliver fortalt, at den ikke kan findes, eller den eksisterer ikke osv. i ansøgningen. Ved hjælp af Process Monitor fandt vi grunden til at være, at mens stien, der bliver bedt om, er C: \ dir1 \ dir2 \ file1.txt, den vej, der evalueres af Windows-systemet, er C: \ dir1 \ .dir2Blah \ file1. txt.


Vi har fundet ud af, at nogle 32-bit applikationer ser ud til at kunne fungere fint med dem (hvad jeg ville kalde) forkerte stier og med succes finde de pågældende filer, men andre gør det ikke.


Som jeg sagde ovenfor, har vi også fundet, at vi kan reproducere problemet med 64-bit applikationer hvis vi forsøger at åbne filen via en cmd.exe-prompt; for eksempel 'textpad.exe \ dir1 \ dir2 \ file1.txt'.


Vi har 'googled' dette problem i 2 dage, fordi vi 'er helt stumped og ikke kan tro på, at ingen andre nogensinde har stødt på dette, hvis det er så' let 'at reproducere. Min kollega og jeg er begge i stand til at forårsage fejlen ; ikke konsekvent, men filadgang vil mislykkes mere end halvdelen af ​​tiden, da vi opsætter den struktur, jeg beskrev.


Jeg har inkluderet et billede af Process Monitor, der viser dette svigt i to applikationer, men lykkes i en tredjedel ... her. [3]


Kan nogen fortælle mig, hvad der foregår? Først hvorfor ændrer den stien til at bruge den skjulte fil i stedet for det angivne katalognavn? Og vigtigere, hvordan kan vi få det til at stoppe ;-)?


Skål,
JTM


Tilføjet senere:


Her er 'dir/x' output for en mappe, hvor jeg har dette problem.


24/05/2017  12:17 PM  <DIR>                    .
24/05/2017  12:17 PM  <DIR>                    ..
24/05/2017  12:17 PM           12 BLAHTS~1     .blahtst
23/05/2017  03:06 PM          104 JSHINT~1     .jshintrc
24/05/2017  12:16 PM  <DIR>                    blah
24/05/2017  12:16 PM            0              blank.txt
24/05/2017  12:15 PM        6,624 INDEX~1.HTM  index.html
24/05/2017  10:48 AM  <DIR>                    js


Det indikerer også, hvordan vi snuble over problemet. Jeg har en html-fil, der forsøger at indlæse en JavaScript-fil under/js-mappen, men der er også en .jshintrc-fil på samme niveau, og min gamle Apache-server kan ikke finde filerne til at betjene dem. Hvis jeg fjerner .Jshintrc-fil, jeg kan komme rundt om dette, men dette projekt er ikke et jeg skabte, og jeg er meget glad for at bare fjerne ting, der er nemmest.

Bedste reference