[SAMBA] Bestand 'verwijderbaar' terwijl open

[Renetjuh]

Ik heb een probleem met onze linux server (binnen het bedrijf). Ik heb deze een tijdje geleden zelf geinstalleerd. Ik ben totaal geen linux kenner, echt veel ervaring heb ik er niet mee. Het delen van directories en bestanden met de rest van het netwerk (Windows 2000) gaat via SAMBA. Maar nu heb ik een probleem m.b.t. het verwijderen van bestanden via het netwerk.

Normaal gesproken is het zo dat als je via een Windows 2000 PC in het netwerk een bestand op de server wilt verwijderen dan moeten alle gebruikers die het bestand op dat moment open hebben staan het eerst afsluiten. Gebeurt dit niet, dan is het bestand niet te verwijderen omdat het in gebruik is. Op de huidige server is dit niet het geval. Het bestand is hier gewoon te verwijderen, ook al staat het ergens open. Wat het nog vreemder is, is dat Windows automatisch de snelkoppelingen aanpast op de client-PC. Deze wijzen na het verwijderen (of hernoemen) van het bestand op de server naar het oude bestand

Is dit een configuratieprobleem van de SMB service?

Ik heb ook al geprobeerd een oplossing te vinden m.b.v. de search en google maar dit helaas zonder resultaat (mede doordat ik niet goed weet waarop ik zou moeten zoeken)

Ik hoop dat iemand mij hiermee kan helpen, aangezien het erg veel tijd kost om elke keer iedereen af te bellen of ze het programma afsloten hebben om er later achter te komen dat ze met een oude versie zitten te werken...


PS: Ik hoop dat ik dit topic in het goede forum heb geplaatst, was aan het twijfelen tussen NWOS en NT

[Maasluip]

Volgens mij had dit ook in SA gekund.

SAMBA gebruikt niet hetzelfde protocol als windows werken en ziet daardoor niet dat een file in gebruik is, dat verklaart waarom je hem kunt wissen. 'it's a feature'.

Dat een shortcut in windows verandert als je het file verandert heb ik ook meermalen gezien bij gewone windows netwerkkoppelingen. Was zelfs heel irritant omdat je in windows zoals je zegt het file niet kunt verwijderen als iemand dat file open heeft, en als je het dan hernoemt worden alle shortcuts (op remote PC's in mijn geval) hernoemd naar de gewijzigde file Dat was abusoluut niet prettig.

[GrimaceODespair]

Zoek eens op oplocks

Misschien kunnen die een uitkomst bieden.

[Psychops]

Samba weet zeker wel welke files er in gebruik zijn. Openmaar eens een bestand op een client en doe op de server dan "smbstatus", je kan dan precies zien welke gebruiker welke files 'gelocked' heeft.
Volgens mij kan je dit verder opzoeken in de man van smb.conf. zoek eens op file locking, moet zeker iets over te vinden zijn

http://us3.samba.org/samba/docs/Samba-HOWTO-Collection.pdf

ik neem aan dat je daar al gekeken hebt ?

[ Voor 18% gewijzigd door Psychops op 22-12-2003 10:27 ]

[Renetjuh]

mdeen schreef op 22 december 2003 @ 10:18:
SAMBA gebruikt niet hetzelfde protocol als windows werken en ziet daardoor niet dat een file in gebruik is, dat verklaart waarom je hem kunt wissen. 'it's a feature'.

Nou, ik heb op andere Linux server meegemaakt dat het wel werkte zoals het hoort dus het moet kunnen (gelukkig )

GrimaceODespair schreef op 22 december 2003 @ 10:25:
Zoek eens op oplocks

Misschien kunnen die een uitkomst bieden.

Ga ik doen, thnx

Psychops schreef op 22 december 2003 @ 10:26:
Samba weet zeker wel welke files er in gebruik zijn. Openmaar eens een bestand op een client en doe op de server dan "smbstatus", je kan dan precies zien welke gebruiker welke files 'gelocked' heeft.
Volgens mij kan je dit verder opzoeken in de man van smb.conf. zoek eens op file locking, moet zeker iets over te vinden zijn

http://us3.samba.org/samba/docs/Samba-HOWTO-Collection.pdf

ik neem aan dat je daar al gekeken hebt ?

hmm, smbstatus, daar kan ik in ieder geval het probleem mee voorkomen. Is niet de oplossing maar werkt wel totdat ik een oplossing heb gevonden. Kan ik tenminste zien of het bestand in gebruik is.

Het Samba-HOWTO document heb ik wel bekeken, maar ik wist niet waar ik naar moest zoeken helaas

[ajvdvegt]

Renetjuh schreef op 22 december 2003 @ 10:35:
[...]
Nou, ik heb op andere Linux server meegemaakt dat het wel werkte zoals het hoort dus het moet kunnen (gelukkig )

Het werkt toch juist precies zoals het hoort? Het juist door de vage filesystem implementatie van Windows dat je bestanden niet kan verwijderen/wijzigen/verplaatsen als ze door iemand anders in gebruik zijn. (dat is ook een reden dat Windows vaak moe(s)t worden gereboot om systeembestanden te updaten, en dat bij Unices niet hoeft)
Het werkt niet zoals je gewend bent misschien, maar dat is wat anders!

[GrimaceODespair]

ajvdvegt schreef op 22 december 2003 @ 10:54:
Het werkt toch juist precies zoals het hoort? Het juist door de vage filesystem implementatie van Windows dat je bestanden niet kan verwijderen/wijzigen/verplaatsen als ze door iemand anders in gebruik zijn.

Niet om een flamewar te starten ofzo, maar eerlijk gezegd vind ik het wel logisch dat je een bestand niet kan verwijderen/wijzigen/verplaatsen als het in gebruik is. Dat is net één van de grondbeginselen van een OS. Dat MS daar een überbrakke implementatie van heeft gemaakt, is iets anders

[Renetjuh]

ajvdvegt schreef op 22 december 2003 @ 10:54:
[...]

Het werkt toch juist precies zoals het hoort? Het juist door de vage filesystem implementatie van Windows dat je bestanden niet kan verwijderen/wijzigen/verplaatsen als ze door iemand anders in gebruik zijn. (dat is ook een reden dat Windows vaak moe(s)t worden gereboot om systeembestanden te updaten, en dat bij Unices niet hoeft)
Het werkt niet zoals je gewend bent misschien, maar dat is wat anders!

GrimaceODespair schreef op 22 december 2003 @ 10:58:
[...]

Niet om een flamewar te starten ofzo, maar eerlijk gezegd vind ik het wel logisch dat je een bestand niet kan verwijderen/wijzigen/verplaatsen als het in gebruik is. Dat is net één van de grondbeginselen van een OS. Dat MS daar een überbrakke implementatie van heeft gemaakt, is iets anders

Kijk, het heeft natuurlijk beide zijn voordelen inderdaad. Maar in mijn geval heb ik graag dat een bestand niet te overschrijven is als het geopend is, vooral om verschillende versies van hetzelfde bestand te voorkomen

[Wilke]

GrimaceODespair schreef op 22 december 2003 @ 10:58:
Niet om een flamewar te starten ofzo, maar eerlijk gezegd vind ik het wel logisch dat je een bestand niet kan verwijderen/wijzigen/verplaatsen als het in gebruik is. Dat is net één van de grondbeginselen van een OS. Dat MS daar een überbrakke implementatie van heeft gemaakt, is iets anders

Niet om hier een flamewar van te maken (beide systemen hebben hun voor- en nadelen), maar afgezien van of je dit 'logisch' of 'onlogisch' vind, het is zeker niet een van de grondbeginselen van een OS dat een file niet te verwijderen/wijzigen/verplaatsen is terwijl het geopend is.

In Windows zit file locking diep geintegreerd in het 'normale' bestandstoegangssysteem. Je kunt er dus niet omheen, ook al zou je dat vaak graag willen (je delete een directory, maar dat mag niet want een of ander lullig bestandje in een subdir is nog in gebruik ).

In UNIX heb je het tegenovergestelde probleem: vaak zou je willen dat een file netjes gelocked zou worden door alle processen die het kunnen openen (zodat bv. niet 2 processen tegelijkertijd in je mailfile schrijven, met onvoorspelbare resultaten), maar omdat dit niet afgedwongen kan worden, hoeft er maar 1 proces te zijn dat dit stiekem niet doet, en de boel loopt in de soep
Uiteraard zijn er wel standaard-libs voor locking, zodat als je 'beschaafde' software gebruikt, dit zelden nog een probleem vormt.

Het verschil is dus, dat je in UNIX de keus hebt (nadeel: daardoor niet keihard af te dwingen), terwijl Windows je dwingt (nadeel: geen keuzevrijheid).

Het is dus een kwestie van smaak welke manier je liever hebt, maar het is dus duidelijk dat dit geen lowlevel taak van het OS hoeft te zijn. Dat kun je er inderdaad wel van maken (wel ja, als je een webbrowser tot lowlevel taak van een OS kunt maken dan moet dit zeker kunnen inderdaad ), maar er kleven zeker ook nadelen aan als je dat doet.

[sirdupre]

Nog even een vraagje (puur uit interesse) hoor: linux gooit een bestand toch pas écht weg, als het niet meer open is? Als twee samba processen een bestand open hebben, en je gooit hem weg, terwijl die processen nog bezig zijn, dan wordt het bestand toch pas echt verwijderd als die processen ook stoppen? Of klopt dat niet....

[Maasluip]

Wilke schreef op 22 december 2003 @ 11:52:
In Windows zit file locking diep geintegreerd in het 'normale' bestandstoegangssysteem. Je kunt er dus niet omheen, ook al zou je dat vaak graag willen (je delete een directory, maar dat mag niet want een of ander lullig bestandje in een subdir is nog in gebruik ).

Nou, het leuke (?) van windows is dan wel dat filelocking ook geen moetje is. Als je bijvoorbeeld een mpegje in de WMP afspeelt, en dat mpegje staat op een door windows geshare netwerkdrive, dan kun je dat mpegje gewoon deleten. WMP blijft ook gewoon doorspelen.

[XTerm]

Het zit eigenlijk zo:

Stel ik heb een file, a en ik open die in een editor. We gaan er vanuit dat de file a veel te groot is om in het ram te kunnen, dus de editor moet regelmatig de disk consulteren.

Nu "verwijder" (rm a) ik de file. In de editor merk je er NIETS van, hij zal nog steeds aan alle data kunnen.

Met ls zie je de file niet meer staan, maar met df zou je kunnen merken dat de ruimte ervoor nog steeds bezet is.

Quit je nu de editor komt deze ruimte meteen vrij...

Het systeem is als volgt. Rm verwijdert (of laat verwijderen), de inode van de file, dus de referentie naar de file is wel weg, maar de datablocks staan er nog gewoon, en zolang een applicatie een geldige streampointer heeft, blijft de kernel de inode data even bijhouden.

Een feature dus

[Wilke]

Wat XTerm zegt beantwoord de vraag van SirDupre eigenlijk al. Het is dus niet direct zo dat Linux "bestanden" wist - maar alleen een verwijzing naar een bestand. Daarom is het ook zo makkelijk om meerdere verwijzingen ("bestandsnamen") te hebben naar een 'fysieke' file (inode).

Als de verwijzingen allemaal weg zijn, kunnen alleen processen die het bestand voor verwijderen al geopend hadden er nog in lezen/schrijven. Als het laatste proces het bestand sluit, is de data eenvoudigweg niet meer terug te vinden (behalve met een lowlevel disk/inode analyzer, bv. een undelete progsel) - de betreffende inodes worden toegevoegd aan de lijst met 'lege' inodes. Er wordt dus niet echt iets verwijderd - behalve het weggooien van de verwijzing gebeurt er verder eigenlijk niks.

Dit is ook de reden dat je de logdaemon moet herstarten nadat je de (reusachtig grote, /var-partitie opvullende) /var/log/messages logfile hebt weggegooid. Doe je dit niet, dan schrijft de logdaemon doodleuk nooit meer te achterhalen logmessages naar de niet meer te bereiken /var/log/messages, en is de ruimte alsnog niet vrijgegeven.

[Olaf van der Spek]

XTerm schreef op 22 december 2003 @ 15:45:
Het zit eigenlijk zo:

Stel ik heb een file, a en ik open die in een editor. We gaan er vanuit dat de file a veel te groot is om in het ram te kunnen, dus de editor moet regelmatig de disk consulteren.

Nu "verwijder" (rm a) ik de file. In de editor merk je er NIETS van, hij zal nog steeds aan alle data kunnen.

Met ls zie je de file niet meer staan, maar met df zou je kunnen merken dat de ruimte ervoor nog steeds bezet is.

Quit je nu de editor komt deze ruimte meteen vrij...

Het systeem is als volgt. Rm verwijdert (of laat verwijderen), de inode van de file, dus de referentie naar de file is wel weg, maar de datablocks staan er nog gewoon, en zolang een applicatie een geldige streampointer heeft, blijft de kernel de inode data even bijhouden.

Een feature dus

Ja, maar wel anders dan wat jij zegt. De inode zelf wordt niet gewist, maar de link van de dir waar het bestand in stond naar de inode wordt gewist.
De inode bevat (IIRC) onder andere waar het bestand op disk staat, dus als je dat wist, zou je editor het wel merken.

Dat Windows je geen keuze laat is ook niet helemaal correct. Je kunt best een bestand openen zonder sharing restricties (zoals in het mail-scenario). Alleen hernoemen/verwijderen kan niet.