DS415 geeft melding: Insufficient capacity for update

[Birdy]

Ah, dus DSM checkt kennelijk eerst of er wel een update uitgevoerd kan worden.

[Chris12]

Ik heb het script nu aangepast en ik zie niet meer in de root directory de addstatus.jsp files terecht komen, maar in de /tmp directory.
Dat laatste stuk van de data in een variable zetten ipv schijf lijkt niet te werken (aangezien ik files zie in /tmp)

Code: [Selecteer]

#folder to temporarily store the upload data when needed
cd /tmp


Zou het werken als ik in dit script direct onder de "cd /tmp" de zogenaamde clean-up regel zet met dit commando:

Code: [Selecteer]

find  -maxdepth 1 -mindepth 1 -type f -name "addstatus.jsp*" -delete
Dan wordt de voorgaande 'addstatus.jsp' regel verwijderd voordat de nieuwe wordt aangemaakt lijkt mij.
Klopt deze beredenering?

/edit/ zojuist aangepast, en dit werkt prima!

[Briolet]

De cleanup is niet strikt nodig. Zeker als hij elke 5 minuten moet zoeken. Op zijn minst de zoekopdracht beperken tot de folder waar de file verwacht wordt.

Alles in /tmp wordt toch na een reboot gewist en als hij bij jou pas na 3 jaar vol gelopen is, zal er tussendoor echt wel een update voorbij gekomen zijn met een reboot.

Beter is het een folder in /tmp te maken en daar de file heen laten schrijven en die folder inclusief inhoud elke keer te wissen. (Een zoekopdracht is verspilling van cpu cycli als je weet waar alles staat)

Maar het script in dit topic uitgebreid bespreken is jammer van de tijd. Er is al een heel uitgebreid topic over dat script. Iemand met problemen zal daar eerder zoeken.

En jammer dat mijn suggestie voor wget niet werkt. De functie van die wget aanroep is er alleen maar om data de uploaden. Misschien dat dit downloaden van data met een extra parameter nog te voorkomen is.

[Briolet]

Ik heb hierboven een link naar dat oude topic geplaatst. En in dat topic heb ik toch maar besloten de eerste versie van het script te editten, zodat het wel veilig gebruikt kan worden.

Een beetje tegen mijn principe om andermans script te editten, maar de plaatser van het script was na april 2017 niet meer ingelogd op dit forum en laat anderen met de problemen van zijn script zitten. En de verbeteringen aan het eind van het draadje zelf, maakt de boel onoverzichtelijk omdat dit uiteindelijk tussen alle latere posts 'verdrinkt'.

[Birdy]

Wel goed opgelost maar, ik vind het sowieso een slecht idee om eigengemaakte scripts te laten schrijven in de DSM partitie.
Laat het gewoon schrijven naar een gedeelde map (cd /volume1/Hosola), dan heb je er zicht op en kan je ermee doen wat je wilt.
 

[Briolet]

Zoals ik al schreef is dit een quick-fix. Als je een share aanmaakt gaat dat erg lastig vanuit een script. (zal vast wel kunnen met de goede systeen call) En als je een losse folder aanmaakt in volume1, moet je heel erg oppassen dat je geen naam kiest die al bestaat, want dan ga je misschien data van gebruikers wissen. Oftewel, het script wordt complexer, of er moet aanvullende uitleg komen hoe het script te gebruiken.

Er klopt wel veel meer niet aan het script. Mij gruwt het b.v. als ik scripts zie waar account gegevens en toegangsdata direct in het script staan. Als je zo'n script doorgeeft moet je er elke keer op letten dat je eerst stukken van je eigen script wegpoetst. Dat gaat een keer mis. (Zoals in het bovenstaande script ook gebeurd is met de sid en key waarden) Variabele data behoort daarom niet in een script te staan, maar in een separate file.

Ook de hele foutafhandeling mist in het script. Als de omvormer b.v. uit staat, of een storing heeft,  gaat het script rustig verder en stuurt ongeïnitialiserde data weg i.p.v. een mailtje met foutmelding.