tiedostojen attribuuttien vaihto - what gives?

[mike.mcfin]

Siirsin USB-levyltä (fat32) 50 gigaa valokuvia iMacciin (HFS+).
Joukossa hakemistoja alihakemistoineen jne. aika syvälle. Osa hakemistoista ja tiedostoista on winkkarissa laitettu aikoinaan kirjoitussuojatuksi.

Miten saan koko tämän hakemistopuun tiedostoineen nyt muokattua kirjoitettavaksi?

Kokeilin finderista ylimmän tason hakemistolla (cmd+i). Poistin lukon ja annoin adminin pwd:n ja lisäsin kirjoitusoikeudet. Valitsin pikkuboksista "käytä sisältyviin kohteisiin" eli jonkunlainen "alihakemistot mukaan" juttu. Ei auta. Pari ekaa hakemistoa muuttuu mutta ei kaikki. Ja silti joukkoon jää tiedostoja joissa on "lukittu" rasti päällä (kohdasta yleiset). Mikä ihme tuo ylipäätään on ja miten sen voi poistaa kerralla kaikista?

Jos hoidan homman terminaalista niin miten täsmälleen? chmodilla mutta mikä poistaa tuon "lukittu" rastin? (Eksakti komento olisi paikallaan).
Ongelma on lähinnä siinä että joka hakemistossa on thumbs.db yms. file joka on "lukittu" (ilmeisesti winkkarin read-only) ja noita tiedostoja ei saa kerralla deletoita spotlightin kautta vaikka se kuinka kyselee, että poistetaanko lukituksesta huolimatta. Ei poista ei.

Vähän sekavasti kerrottu mutta toivottavasti joku ymmärsi ja osaisi vastata. En viitsi aloittaa importtausta apertureen ennenkuin nuo oikat ovat kunnossa joten pikaista apua kaivataan.

Kiitos.

[tkt]

Komentoriviltä

Koodi: Valitse kaikki

chflags -R nouchg hakemisto_nimi

--Ari

[mike.mcfin]

Komentoriviltä

Koodi: Valitse kaikki

chflags -R nouchg hakemisto_nimi

--Ari

Suunnattomat Kiitokset !
Onneksi en aloittanut hommia eilen kun homppu oli muutossa. Mihin sitä joutuisikaan ilman...

[Tron]

Minulla on sama ongelma. Olin jo etsimässä tähän ongelmaan vastausta Hompun ETSI-toiminolla, mutta "Kirjoitussuojaus"-haulla ei löytynyt järkevää. Sen sijaan huomasin sattumalta tämän attribuuttikysymyksen.

Kokeilin antamaanne komentoa
"chflags -R nouchg hakemisto_nimi"

Komento meni tyylikkäästi läpi ilman virheilmoituksia, mutta kyseisen hakemiston tiedostot ovat edelleen kirjoitussuojattuja! Mikä mättää?

Eikö hommaa voi hoitaa mitenkään graafisella käyttöliittymällä, kun tuo komentomoodi on vähän kinkkinen mulle, kun en ole tottunut käyttämään sitä Mac-koneissa? Voisiko homman tehdä esim. kansiotoimintojen skripteillä? (Mulla ei ole kokemusta niistä, mutta on joku käsitys joka tosin voi olla väärä.)

[Lare]

10.4 käyttikellä BatChmod-ohjelmalla korjailin näitä lukittumisia. 10.5:ssä ei ole vielä tarvinnut korjailla, eikä tuo virallisesti sitä taida tukeakaan.

[mike.mcfin]

Kokeilin antamaanne komentoa
"chflags -R nouchg hakemisto_nimi"

Komento meni tyylikkäästi läpi ilman virheilmoituksia, mutta kyseisen hakemiston tiedostot ovat edelleen kirjoitussuojattuja! Mikä mättää?)

Tarvitset kaiketi myös sen chmod:in ajamisen mikäli tiedostojen oikeudetkin ovat rajoitettu. Ehkäpä myös chown:in.
Koska en muista ulkoa tarkkoja parametreja jätän sen paremmin tietävien vastattavaksi.
Oliskohan ollut chmod -R 644 kansion_nimi. Eli r/w omistaja. Muut r.

[Tron]

Tarvitset kaiketi myös sen chmod:in ajamisen mikäli tiedostojen oikeudetkin ovat rajoitettu. Ehkäpä myös chown:in.

Ovatko nuo käyttöjärjestelmän komentoja? (En tunne UNIXia, pari komentoa tiedän sattumalta.)

Olen "räplännyt" tietokoneita (DOS jne) yli neljännesvuosisadan enkä ole kertaankaan huomannut mitään oikeaa käytännön hyötyä kirjoitussuojauksesta. Siitä on ollut vain ja ainoastaan haittaa monessa yhteydessä. Koko ominaisuuden voisi poistaa. Jos joku ajattelee että sillä estetään tiedoston muuttaminen vahingossa, niin se ei käytännössä pidä paikkaansa. Sen ansiosta tulee vain ylimääräinen huomautus että tiedosto on kirjoitussuojattu, muutetaanko tiedostoa silti. Ja refleksinä tuleva vastaus on on KYLLÄ.

Ja jos tiedostoa muuttaa jokin ohjelma automaattisesti ilman käyttäjän myötävaikutusta, niin käytännössä ohjelmaan joudutaan laitamaan lisärivi jolla kirjoitussuojaus poistetaan automaattisesti. (Lisäharmi sekin.)

Ja tätäkin keskustelua käydään vain sen takia, koska kirjoitussuojaus on ongelma.

[gramdel]

Tarvitset kaiketi myös sen chmod:in ajamisen mikäli tiedostojen oikeudetkin ovat rajoitettu. Ehkäpä myös chown:in.

Ovatko nuo käyttöjärjestelmän komentoja? (En tunne UNIXia, pari komentoa tiedän sattumalta.)

Olen "räplännyt" tietokoneita (DOS jne) yli neljännesvuosisadan enkä ole kertaankaan huomannut mitään oikeaa käytännön hyötyä kirjoitussuojauksesta. Siitä on ollut vain ja ainoastaan haittaa monessa yhteydessä. Koko ominaisuuden voisi poistaa. Jos joku ajattelee että sillä estetään tiedoston muuttaminen vahingossa, niin se ei käytännössä pidä paikkaansa. Sen ansiosta tulee vain ylimääräinen huomautus että tiedosto on kirjoitussuojattu, muutetaanko tiedostoa silti. Ja refleksinä tuleva vastaus on on KYLLÄ.

Ja jos tiedostoa muuttaa jokin ohjelma automaattisesti ilman käyttäjän myötävaikutusta, niin käytännössä ohjelmaan joudutaan laitamaan lisärivi jolla kirjoitussuojaus poistetaan automaattisesti. (Lisäharmi sekin.)

Ja tätäkin keskustelua käydään vain sen takia, koska kirjoitussuojaus on ongelma.

Joo, näin ehkä vain yhden käyttäjän/yhdelle käyttäjälle suunnatussa järjestelmässä.

Jos nyt haluaa lisätä kirjoitusoikeuden vaikkapa vain tiedoston omistajalle, onnistuu se terminaalista komennolla chmod u+r tiedostonnimi ja siis koko hakemistolle kerralla chmod -R u+r hakemistonnimi. Jos taas haikailee, että kaikilla on kirjoitusoikeus, niin chmod +r ja aikaisemmat rimpsut. Ja tosiaan, jos tiedoston omistaja on joku muu kuin haluttu käyttäjä tarvitsee chownin.

/---
ap

[Tron]

Joo, näin ehkä vain yhden käyttäjän/yhdelle käyttäjälle suunnatussa järjestelmässä.

Jos nyt haluaa lisätä kirjoitusoikeuden vaikkapa vain tiedoston omistajalle, onnistuu se terminaalista komennolla chmod u+r tiedostonnimi ja siis koko hakemistolle kerralla chmod -R u+r hakemistonnimi. Jos taas haikailee, että kaikilla on kirjoitusoikeus, niin chmod +r ja aikaisemmat rimpsut. Ja tosiaan, jos tiedoston omistaja on joku muu kuin haluttu käyttäjä tarvitsee chownin.

ap

Eivätpä nuo antamasi komennot muuttaneet tilannetta. Tiedostot ovat edelleenkin kirjoitussuojattua.

Mitä kirjoitussuojaukseen tulee, niin sitä pitänee katsoa kahdelta kantilta:

Ensinnäkin tiedostoilla on erilaisia käyttäjästä riippuvia oikeuksia. Yhdellä käyttäjällä voi olla oikeudet lukea ja kirjoittaa johonkin tiedostoon, toisella voi olla oikeus vain lukea sitä mutta ei muuttaa ja kolmas ei voi edes lukea tiedostoa.

Mutta sitten on olemassa käyttäjästä riippumaton kirjoitussuojaus. Tällainen on esim disketissä ollut muovilämyskä, jonka laittaminen toiseen asentoon teki disketistä kirjoitussuojatun. Vastaavasti yksittäisiä tiedostoja pystyi tekemään kirjoitussuojatuksi vääntämällä siihen liittyvä attribuutti toiseen asentoon, vaikkapa suoraan disketille. Tämän disketin pystyi tunkemaan tietenkin mihinkä koneeseen tahansa, eikä näin kirjoitussuojaus voi mitenkään olla käyttäjäriippuva.

CD-R levyn tiedostot kun ovat vain luettavia, niin ehkäpä poltto-ohjelma on kaikessa viisaudessaan laittanut niihin attribuutin "read only" talletuksen yhteydessä.

Saman kirjoitussuojausongelman olen havainnut kun olen lukenut rompuilta hakemistoja Windows koneeseen. Mutta Windows koneessa koko hakemiston attribuutit on saanut käännettyä helposti, vieläpä graafisella käyttöliittymällä tarvitsematta mennä komentomoodiin. Luulisi että vastaava on mahdollista myös OS X:ssä?

Vai eikö OS X mahdollisesti tavoita Windows koneen määrittelemiä attribuutteja aina oikein? Olen huomannut muitakin epämääräisyyksiä liittyen tiedostomäärittelyihin kun tiedostoja siirretään välillä Windows-kone / Mac. Esimerkkinä se että tiettyjen valokuvatiedostojen kelloaika näkyy erilaisena Windows koneessa ja Macissa. (Ei EXIF-tiedostossa, vaan hakemistolistauksissa.) Eroa on jostain syystä kaksi tuntia.

(Nämä tiedostot joita haluan editoida, on luotu vuonna 2002. Saahan niitä editoitua kirjoitussuojauksesta huolimatta, mutta periaatteessa tuo suojaus pitäisi saada pois.)

[mike.mcfin]

Ja tätäkin keskustelua käydään vain sen takia, koska kirjoitussuojaus on ongelma.

Ehkäpä tässä on eräs käytännön esimerkki HFS+ :ssa ilmenevistä ominaisuuksista joita herra Torvalds hetki sitten kritisoi. Huomasin nimittäin myös itse ettei chflags+chown+chmod muuttanut kaikkia tiedostoja. Joissakin näkyy edelleen se pikkupallukka readonly-flagin merkkinä ja näitä tiedostoja saa sitten tuurilla joko poistettua tai ei saa ilman mitään logiikkaa.

[tkt]

Ja tätäkin keskustelua käydään vain sen takia, koska kirjoitussuojaus on ongelma.

Ehkäpä tässä on eräs käytännön esimerkki HFS+ :ssa ilmenevistä ominaisuuksista joita herra Torvalds hetki sitten kritisoi. Huomasin nimittäin myös itse ettei chflags+chown+chmod muuttanut kaikkia tiedostoja. Joissakin näkyy edelleen se pikkupallukka readonly-flagin merkkinä ja näitä tiedostoja saa sitten tuurilla joko poistettua tai ei saa ilman mitään logiikkaa.

Miksi Torvalds olisi kritisoinut tiedostojen käyttöoikeuksia? Täsmälleen samanlainen on Linuxin tiedostojärjestelmissä. Kritiikki kohdistui pikemminkin HFS:n ikään ja pitkään kehittymispolkuun kun uusia ominaisuuksia on lisätty, minkä johdosta se ei ole kaikilta osin niin virtaviivainen, kuin mitä sen pitäisi olla Torvaldsin mielestä.

Syy miksi et ole kaikkia oikeuksia saanut muutettua chown+chmod+chflags -komennoilla on ilmeinen. Tiedoston oikeuksia ei voi muuttaa, jos siihen ei ole kirjoitusoikeuksia. Komennon suorittamisen ajaksi pitää ottaa käyttöön korotetut oikeudet, jolloin asetus menee perille. (sudo chmod ...) Samaa tarkoittaa Näytä yleistiedot -ikkunassa oleva lukko.

--Ari

PS. Käyttöoikeudet eivät ole ongelma. Ongelma on itseasiassa ihan muualla kuin tietokoneessa.

[tkt]

CD-R levyn tiedostot kun ovat vain luettavia, niin ehkäpä poltto-ohjelma on kaikessa viisaudessaan laittanut niihin attribuutin "read only" talletuksen yhteydessä.

Kun katson CD-levyn tiedostojen käyttöoikeuksia, huomaat heti että niihin on kirjoitusoikeudet ihan samalla tavalla kuin muihinkin levyihin. Silti tiedostoja ei voi muuttaa CD-levyllä. Tämä johtuu siitä, että CD-levyn tiedostojärjestelmä on kokonaisuudessaan vain luettavissa oleva.

Saman kirjoitussuojausongelman olen havainnut kun olen lukenut rompuilta hakemistoja Windows koneeseen. Mutta Windows koneessa koko hakemiston attribuutit on saanut käännettyä helposti, vieläpä graafisella käyttöliittymällä tarvitsematta mennä komentomoodiin. Luulisi että vastaava on mahdollista myös OS X:ssä?

Finderin Näytä yleistiedot -ikkunassa on mahdollisuus vaihtaa hakemistojen ja tiedostojen oikeuksia. Joskus on helpointa ja yksikäsitteisintä neuvoa komentorivin käyttöä.

Vai eikö OS X mahdollisesti tavoita Windows koneen määrittelemiä attribuutteja aina oikein? Olen huomannut muitakin epämääräisyyksiä liittyen tiedostomäärittelyihin kun tiedostoja siirretään välillä Windows-kone / Mac. Esimerkkinä se että tiettyjen valokuvatiedostojen kelloaika näkyy erilaisena Windows koneessa ja Macissa. (Ei EXIF-tiedostossa, vaan hakemistolistauksissa.) Eroa on jostain syystä kaksi tuntia.

Mac OS X käyttää UNIXien tapaan tiedostojen aikaleimassa, kuten muissakin aikatiedoissa, UTC-aikaa. Suomen aika on talvella kaksi ja kesällä kolme tuntia edellä UTC-aikaa. Näin ollen eripuolilla maailmaa samanaikaisesti luoduilla tiedostoilla on yhteneväinen aikaleima. Windows-koneissa aikaleimat ovat paikallista aikaa eli samanaikaisesti luoduilla tiedostoilla voi olla erilainen aikaleima tai ne voivat olla todellisuuteen nähden käänteisessä järjestyksessäkin.

--Ari

[Tron]

CD-R levyn tiedostot kun ovat vain luettavia, niin ehkäpä poltto-ohjelma on kaikessa viisaudessaan laittanut niihin attribuutin "read only" talletuksen yhteydessä.

Kun katson CD-levyn tiedostojen käyttöoikeuksia, huomaat heti että niihin on kirjoitusoikeudet ihan samalla tavalla kuin muihinkin levyihin. Silti tiedostoja ei voi muuttaa CD-levyllä. Tämä johtuu siitä, että CD-levyn tiedostojärjestelmä on kokonaisuudessaan vain luettavissa oleva.

Se on selvää että CD-R levyllä olevaa tiedostoa ei voi muuttaa. On vaan ikävä sivuvaikutus, että jos jokin hakemisto tekee reitin "tietokone -> CD-R -> tietokone", niin sivuvaikutuksena tuon kierroksen jälkeen kaikki hakemiston tiedostot ovat kirjoussuojattuja myös ollessaan takasin omalla koneella. Se takia poltan nykyään kaikki hakemistot ZIPattuina. (Siihen on muitakin syitä.) ZIPin kun purkaa, niin puretun kohdehakemiston attribuutit ovat ennallaan.

Saman kirjoitussuojausongelman olen havainnut kun olen lukenut rompuilta hakemistoja Windows koneeseen. Mutta Windows koneessa koko hakemiston attribuutit on saanut käännettyä helposti, vieläpä graafisella käyttöliittymällä tarvitsematta mennä komentomoodiin. Luulisi että vastaava on mahdollista myös OS X:ssä?

Finderin Näytä yleistiedot -ikkunassa on mahdollisuus vaihtaa hakemistojen ja tiedostojen oikeuksia. Joskus on helpointa ja yksikäsitteisintä neuvoa komentorivin käyttöä.

Enpä ole hoksannut että homma menee noin yksikertaisesti Finderin kautta. Ei ole ollut ennen tarvetta tuolle. Kiitos kuitenkin vinkistä, tuo oli sata kertaa yksinkertaisempaa kuin komentorivin käyttö. Nyt kyseisten ongelmahakemistojen kirjoitussuojaus on poissa.

Vai eikö OS X mahdollisesti tavoita Windows koneen määrittelemiä attribuutteja aina oikein? Olen huomannut muitakin epämääräisyyksiä liittyen tiedostomäärittelyihin kun tiedostoja siirretään välillä Windows-kone / Mac. Esimerkkinä se että tiettyjen valokuvatiedostojen kelloaika näkyy erilaisena Windows koneessa ja Macissa. (Ei EXIF-tiedostossa, vaan hakemistolistauksissa.) Eroa on jostain syystä kaksi tuntia.

Mac OS X käyttää UNIXien tapaan tiedostojen aikaleimassa, kuten muissakin aikatiedoissa, UTC-aikaa. Suomen aika on talvella kaksi ja kesällä kolme tuntia edellä UTC-aikaa. Näin ollen eripuolilla maailmaa samanaikaisesti luoduilla tiedostoilla on yhteneväinen aikaleima. Windows-koneissa aikaleimat ovat paikallista aikaa eli samanaikaisesti luoduilla tiedostoilla voi olla erilainen aikaleima tai ne voivat olla todellisuuteen nähden käänteisessä järjestyksessäkin.
--Ari

Keljua tuossa on se että jos mulla on Mac koneessa yhdet aikaleimat, sitten kopion Windows koneeseen ja sieltä takaisin Mac koneeseen, niin aikaleimat ovat silti siirtyneet kahdella tunnilla. Luulisi että kahden tunnin aikasiirtymä palaa takasin kun siirtää tiedostot takaisin Mac koneeseen. Mutta ei. (Tässä on toinen syy miksi varakopioin hakemistoja toiseen koneeseen pääasiassa zipattuina.)

Myös kuvien orientaatiotageissa on ongelmia siirrossa Mac/Windows. Jos kuvan kääntää 90 astetta esikatselulla ja kuvan siirtää Windows koneeseen, niin kuva voi olla väärässä asennossa Windows koneessa. Jos käännön tekee GraphicConverterilla, niin silloin tuota ongelmaa ei ole.