Miks mõned Windowsi faili- ja kaustade nimed on nende ees?
Kuigi enamik meist näeb meie Windowsi süsteemides tavapäraseid faili- ja kaustanimesid, võivad teised inimesed olla kohanud midagi veidi ootamatumat - failide ja kaustade nimesid nende ees. Miks see juhtub? Tänase SuperUser Q&A postituse vastus on väga uudishimulik lugeja küsimus.
Tänane küsimuste ja vastuste seanss saabub meiega kohtades, kus on SuperUser-Stack Exchange'i alajaotis, kogukondlikult juhitav Q&A veebisaitide rühmitus.
Foto viisakalt Domirielilt (Flickr).
Küsimus
SuperUser-lugeja Niko Bellic tahab teada, miks mõnel Windowsi faili- ja kaustanimel on nende ees punkt:
Näiteks Minu dokumendid minu Windowsi süsteemis on leitud järgmised kaustad:
- .ssh
- .subversion
Kas see on mingisugune nimetamise konventsioon, mida ma ei tea?
Miks on mõnedel Windowsi failide ja kaustade nimedel nende ees punkt?
Vastus
SuperUser-i panuse andja vastus on meile vastus:
See nimetuskonventsioon pärineb Unixi sarnastest operatsioonisüsteemidest (nagu Linux või OSX), kus see tähendab a peidetud fail või kataloog. See toimib kõikjal, kuid selle esmane kasutus on peita konfiguratsioonifailid oma kodukataloogis (st. ~ / .cache / või ~ / .plan) Neid kutsutakse sageli dot-failid.
Dot-failid mõnevõrra võiks seda nimetada traditsiooniliseks Unixiks Äppiandmed kataloogi Windows. Samal ajal muudetakse palju Linuxi programme, et järgida XDG baasi kataloogi spetsifikatsiooni, liigutades nende konfiguratsiooni ~ / .config / ja muud andmed ~ / .cache / ja ~ / .local / share /. See muudab selle sarnasemaks AppData Rändlus ja AppData kohalik.
Sul on need .ssh ja .subversion Windowsi kataloogid, sest olete kasutanud mõningaid programme (konkreetselt OpenSSH ja Subversion), mis on teisaldatud Windowsi süsteemi API-de kasutamiseks POSIXi asemel, kuid mida ei ole mõne teise Windowsi konventsiooniga kohandatud.
Mõnikord jäetakse see kohandamine sihilikult vahele, et lihtsustada nende inimeste elu, kes kasutavad oma Windowsi süsteemides Unixi sarnaseid keskkondi, nagu näiteks Cygwin. Näiteks paigaldab Cygwin Unixi sarnaste tööriistade standardse komplekti ls, mis ignoreerib Windowsi varjatud lipp ja austab ainult dot-fail nimed. Samuti on lihtsam sünkroonida konfiguratsiooni üksikisiku Windowsi ja Linuxi / BSD / OSX arvutite vahel, kui seda jagatakse samas asukohas.
Need failid leiduvad tavaliselt kasutaja kodukataloogis (st. /home/name/.ssh Linuxis või C: kasutaja nimi ssh Windows 7 ja hilisemates versioonides). On üsna haruldane, et nad pannakse Dokumendid või Minu dokumendid alamkataloogid (need ei sisalda dokumente).
Kuna Rob Pike kirjutab teenuses Google+, oli see juhuslik funktsioon:
Kaua aega tagasi, kui Unixi failisüsteemi kujundus töötati välja, olid need kirjed . ja … navigeerimise hõlbustamiseks. Ma ei ole kindel, aga ma usun … versiooni 2 ümberkirjutamise ajal, kui failisüsteem muutus hierarhiliseks (selle struktuur oli väga erinev). Kui üks kirjutatakse ls, need failid aga ilmusid, nii et kas Ken või Dennis lisasid programmile lihtsa testi. See oli siis kokkupanekul, kuid kõnealune kood oli samaväärne sellega, nagu:
- kui (nimi [0] == '.') jätkub;
See väide oli veidi lühem, kui oleks pidanud olema:
- kui (strcmp (nimi, „.”) == 0 || strcmp (nimi,…)) == 0) jätkata;
Aga hei, see oli lihtne ja tulemuseks oli kaks asja.
Esiteks määrati halb pretsedent. Paljud teised laiskad programmeerijad kasutasid sama lihtsustamisega vigu. Tegelikud failid, mis algavad perioodidega, jäetakse tihti vahele, kui neid tuleks lugeda.
Teiseks, ja palju hullem, idee a peidetud või dot-fail loodi. Selle tulemusena hakkasid enam laisk programmeerijad igaühe kodukataloogis faile kukutama. Mul ei ole arvutisse installitud palju tarkvara, mida ma seda kasutan, kuid minu kodukataloogil on umbes sada dot-failid ja ma isegi ei tea, millest enamik neist on või kas neid on veel vaja. See kogunenud muda aeglustab iga minu kataloogi läbiva failinime hindamist.
Kas teil on midagi lisada selgitusele? Heli on kommentaarides välja lülitatud. Kas soovite lugeda rohkem vastuseid teistelt tech-savvy Stack Exchange'i kasutajatelt? Vaadake siin täielikku arutelu lõiku.