43 replies to this topic

[40H3X]

Zoals ik eerder aanhaalde, misschien iemand "zorgen" had voor een write-back caching?

[WanWizard]

Je wilt toch voorkomen dat je die file verwijdert per abuis....? Zeker als een ander device er mee bezig is via de NAS...

 

Eh, deze kluts heeft niks met een eventuele "are you sure" vraag te maken, het is gewoon een hack om te voorkomen dat O_BUSY moet worden afgevangen.

 

Aan de "are you sure" afhandeling hoeft niks aangepast te worden, daar is niks mis mee, en daar gaat het probleem ook helemaal niet over.

 

Het probleem is hier dat local current time wordt vergeleken met file mtime, en die kunnen hele verschillende bronnen hebben (en zijn derhalve niet in 1 vergelijking te zetten).

 

En dan kom je bij de vraag "waarom zit deze hack er in", en daarvan schrijft Mike
 

If recording, recording will be stopped, repeating timers will be cancelled just once.
If the file appears to be in the progress of writing, you get a warning (file busy),
for example when another box is recording to a NAS.

 

dus, het kan voorkomen dat al de opname is afgelopen, er nog een stukje buffer geleegd moet worden, en op die write wilde hij wachten.

 

Dit is echter alleen maar relevant als er lokaal wordt opgenomen, door de lokale enigma. Als de Enigma in kwestie niet lokaal is tov de folder waarin de file staat (hetzij NAS, hetzij local disk geshared naar een andere box), dan gaat dit allemaal niet op.

 

En ook kun je gewoon op de rode delete knop drukken in het midden van een opname door een andere box, daar heeft de lokale Enigma ook geen weet van.

 

Kortom, deze code deugt alleen maar in het enge "lokale opname op lokaal device" scenario.

 

Terwijl het probleem dat opgelost moet worden is "kan het bestand worden verwijderd?" en wat als dat niet kan (om whatever reden)? Want nu krijg je een onzinnige "busy" foutmelding, terwijl de file helemaal niet in gebruik is.

Edited by WanWizard, 29 May 2024 - 15:48.

[littlesat]

Het probleem is hier dat local current time wordt vergeleken met file mtime, en die kunnen hele verschillende bronnen hebben (en zijn derhalve niet in 1 vergelijking te zetten).

->

Dit begrijp ik uiteraard wel... maar 'klokken' horen uiteraard goed te staan. Ergens een foute klok kan meer ellende veroorzaken dan alleen deze check die anders kan/moet.

[WanWizard]

Kan allemaal wel, maar dat kan je niet garanderen.

 

Bv als twee boxen een interne disk delen, en beide boxen transponder time gebruiken. Ihmo een veel meer voorkomend scenario dan mensen die hun hele netwerk aan de NTP hebben hangen....

 

En dus mogen we die assumptie niet maken.