Synology-Forum.nl
Packages => Officiële Packages => Cloud Station & Drive => Topic gestart door: Peter van Heun op 04 maart 2018, 15:14:39
-
Ik heb sinds enkele dagen een merkwaardig maar vervelend akkefietje met Cloud Station Server en xls-bestanden. Als ik een xls-bestand open, bewaart Cloud Station Server dat bestand meteen. Ook als ik het geopend bestand niet opsla. Het gebeurt alleen met xls-bestanden, niet met doc, xlsx of andere bestanden. Zodra ik het pakket stop zet, heb ik er geen last meer van.
Iemand een hint waardoor het komt of wat ik aan kan doen?
-
Cloud Station, zowel Server als Client, synchroniseren een xls meteen omdat ze zien dat de datum en tijd wijzigen zodra het xls-bestand geopend wordt. Dat de datum en tijd wijzigt van een xls is altijd zo geweest. Echter, ik ervaar het pas sinds enkele weken als een probleem in synchronisatie. Helaas bestaat er geen oplossing voor. Aangezien ik een heleboel xls-bestanden heb en gebruik, is Cloud Station wel een stuk minder handig geworden.
NB. Synology is op de hoogte.
-
Ik kan me herinneren de Apple invoerde dat de scrolpositie van een pdf onthouden werd. Daarvoor werd de metadata van een pdf constant geupdate. Als je dan door een pdf scrolde, zag je dat er meer dan 1 versie per seconde naar de server ging en was je na 30 seconden scrollen al door je 32 versies heen.
Dat was snel opgelost. (Of door Apple of door CS).
-
Zou iemand die ook Cloud gebruikt eens willen kijken of bij hem/haar hetzelfde gebeurt? Dus gewoon een xls openen en sluiten zonder opslaan. Neemt het xls-bestand op de Cloud Server dan de datum en tijd van het openen over?
-
Zo werkt het niet.
Als je met excel (of een andere microsoft office applicatie) een bestand opent, dan wordt er een werkbestand met dezelfde naam en wat extra karakters (ik dacht beginnende met ~$) aangemaakt, dat is het werk bestand van excel.
Als je nu aanpassingen aan maakt worden bij het opslaan die aanpassingen in het originele bestand doorgevoerd en op dat moment wordt pas de datum van je excel bestand aangepast.
Als je niets wijzigt dan wordt ook de datum van dat bestand niet aangepast.
Waar jij "last" van hebt is dat cloudsync die werkbestanden gaat syncen.
Dit is niet te voorkomen tenzij je het excel bestand eerst naar een andere locatie kopieert (buiten de sync) en dan pas met excel opent.
-
Als die werkbestanden een eigen extensie of een ander uniek stuk in de naam gebruiken, kun je misschien als uitzondering instellen om niet te syncen.
Als ze b.v. allen met ~$ beginnen kun je een filter instellen op "~$*.*". (Zie manual van Drive voor de goede syntax)
Onder Cloud Station kun je dergelijke filters volgens mij alleen in de cliënt instellen. Bij Drive kan dat ook in het admin-console voor alle cliënten.
-
Bij xls worden er geen werkbestanden aangemaakt. De xls zelf wijzigt van datum. Bij xlsx worden wel werkbestanden gebruikt.
Ik kan xls uitsluiten maar ik wijzig er dagelijks ook wat.
-
Als je wat wijzigt kun je ze beter meteen als xlsx opslaan.
Is zo wie zo handiger want er komt een tijd dat xls format niet meer ondersteund zal worden voorspel ik.
-
Excel is zo standaard dat die ondersteunling er lang zal blijven. Sterker. ik had vroeger eens heel oude Appleworks spreadsheets. Ik kon die alleen nog in het moderne numbers krijgen door met die oude Appleworks versie, op de oude PC, in excel formaat te bewaren en dan met Numbers weer in te lezen.
Numbers kon wel dat oeroude Excel formaat lezen, maar de ondersteuning van Apples eigen Appleworks-formaat was al lang uit de code geschrapt.
Ik heb zelf geen excel en moet ze altijd naar Numbers converteren. Dan loopt het werken met de oudere formaten meestal soepeler. Hoewel ook Numbers standaard naar xlsx exporteert, kent hij ook xls als export formaat.
-
Vroeger is dood.
Tegenwoordig wordt ondersteuning voor oude software veel eerder afgebouwd.
Overigens kan ik ook geen ondersteuning voor visicalc en lotus 123 bestanden meer krijgen. :'(
Maar het ging bij deze om de datum wijziging die bij xlsx niet meer optreed en het dus handiger is bij wijzigingen als xlsx op te slaan.
-
Het vraagt een consequente aanpak van eerst een kopie van de originele xls te maken en die dan op slaan naar een recenter Excel formaat (xlsx of xlsm). Maar ik denk dat ik dat toch maar moet gaan doen.
-
Waarom zou je eerst die xls versie een kopie van willen maken.
Dat doe je toch ook niet als hem normaal wijzigt.
Je kun hem in excel gewoon even converteren en dan is het een .xlsx versie geworden.
-
Als ik van tevoren weet dat ik het xls-bestand ga wijzigen hoef ik inderdaad niet eerst een kopie te maken. Regelmatig wil ik echter een xls-bestand inzien zonder dat ik iets wijzig.
-
Microsoft heeft ook een xls viewer.
Die zal niets wijzigen.
Kun je gewoon gratis bij Microsoft downloaden.
-
Welke OS en versie van Excel gebruik je?
Mijn Excel 2013 op Win10 Home doet niet de datum wijzigen, ik herken het probleem dan ook niet.
Ik ken het wel van oudere systemen.
-
Office 2010 onder Windows 10. Wijzigt Excel 2013 de datum vaneen xls-bestand niet meteen nadat het geopend is? De Excel in Office 365 doet dat wel.
-
Na een tijdje geen Cloud Server meer gebruikte hebben (in plaats daarvan een VPN-verbinding), maar eens Drive geprobeerd. Precies hetzelfde euvel. Een xls openen zonder opslaan wordt meteen als een wijziging geregistreerd door Drive... :'(
-
Waarschijnlijk veranderd er ook direct iets bij openen. Hetzelfde gebeurde een tijdje terug bij het scrollen door een pdf. macOS bewaart de cursorpositie in de metadata van de file. Die werd daardoor bij het scrollen een paar keer per seconde geupdate. Gelijktijdig zag je drive een paar keer per seconde de versie vernieuwen.
Dat euvel ik inmiddels opgelost. Blijkbaar heeft Drive geleerd om niet meer op verandering van die metadata van de cursorpositie te reageren. Maar dat betekend wel dat de synchronisatie tussen apparaten niet meer perfect is. Het blijft een keus welke veranderingen Drive mag negeren. Het kan zijn dat iets dergelijks ook met het xls bestand speelt.
-
Het had iets met het programmaatje 'inotify' te maken dat Cloud gebruikt, las ik eens een achtergronddocument van Cloud, en blijkbaar Drive ook. Het fijne weet ik er niet van.
Ik had trouwens nog de Cloud Cliënt op mijn laptop staan. Die gebruikte ik ook niet meer maar nu die weg is lijkt het probleem verholpen... :D. Ben alleen bang het weer terug komt als ik op een andere NAS Drive ShareSync wil gaan gebruiken.
-
Er bleek wat vertraging is de service te zitten. Data van xls-bestanden worden weer gewoon aangepast na openen zonder opslaan. :twisted:
-
is er niet iets veranderd in MS Office (een update of zo) die XLS bestanden meteen omzet naar XLSX (ik weet dat de webvariant dit bijvoorbeeld doet...)? Of loopt er een VBA project mee? Er móét toch een trigger zijn waarom het bestand verandert en daarmee gaat syncen...
-
Kijk ook eens in het logbestand van drive of je daar een reden van de update zien. Ik heb voor de aardigheid een file met naam "Fibonatie berekening" in "Fibonatie berekeningen" veranderd. Dat resulteerd direct in de volgende 8 logregels:
2020-11-25T19:25:07 ( 672:19296) [INFO] event-manager.cpp(743): PushEvent = [Event<FileRenameEvent>[1]{source: local, type: file, file_id: '', parent_id: '', path: '/Fibonatie berekening.numbers', sync_id: 0, max_id: 0, file_size: 0, file_mtime: 0, file_hash: , ea_size: 0, ea_hash: , exec_bit: 0, permanent_link: , uid: 0, gid: 0, mode: 0, acl: , acl_hash: , share_priv_disabled = 0, share_priv_deny_list = , share_priv_ro_list = , share_priv_rw_list = , share_priv_hash = , is_force: 0, is_snapshot: 0, is_mergeable: 1}, to_path: /Fibonatie berekeningen.numbers].
2020-11-25T19:25:07 ( 672:89888) [INFO] event-manager.cpp(301): PullEvent: Event<FileRenameEvent>[1]{source: local, type: file, file_id: '', parent_id: '', path: '/Fibonatie berekening.numbers', sync_id: 0, max_id: 0, file_size: 0, file_mtime: 0, file_hash: , ea_size: 0, ea_hash: , exec_bit: 0, permanent_link: , uid: 0, gid: 0, mode: 0, acl: , acl_hash: , share_priv_disabled = 0, share_priv_deny_list = , share_priv_ro_list = , share_priv_rw_list = , share_priv_hash = , is_force: 0, is_snapshot: 0, is_mergeable: 1}, to_path: /Fibonatie berekeningen.numbers
2020-11-25T19:25:07 ( 672:89888) [INFO] error-handler.cpp(77): Worker (5332): Handle error: Successful.
2020-11-25T19:25:07 ( 672:89888) [INFO] event-manager.cpp(313): DoneEvent: Event<FileRenameEvent>[1]{source: local, type: file, file_id: '', parent_id: '', path: '/Fibonatie berekening.numbers', sync_id: 0, max_id: 0, file_size: 0, file_mtime: 0, file_hash: , ea_size: 0, ea_hash: , exec_bit: 0, permanent_link: , uid: 0, gid: 0, mode: 0, acl: , acl_hash: , share_priv_disabled = 0, share_priv_deny_list = , share_priv_ro_list = , share_priv_rw_list = , share_priv_hash = , is_force: 0, is_snapshot: 0, is_mergeable: 1}, to_path: /Fibonatie berekeningen.numbers
2020-11-25T19:25:07 ( 672:33344) [INFO] event-db.cpp(1177): No record for event-path: [/Fibonatie berekening.numbers]
2020-11-25T19:25:07 ( 672:33344) [INFO] pullevent-handler.cpp(643): Server delete event [/Fibonatie berekening.numbers] and cannot find db record (server fake)
2020-11-25T19:25:07 ( 672:33344) [INFO] pullevent-handler.cpp(662): File [/Fibonatie berekeningen.numbers] is already up-to-date (server echo, event sync id: 47975, db sync id: 47975).
2020-11-25T19:25:07 ( 672:94208) [INFO] pullevent-handler.cpp(111): Set session 1's sync_id to 47975.
Er wordt dus erg veel gelogd. Op de mac staat het logbestand in "~/.SynologyDrive/log/daemon.log". Het is alles heel cryptisch, maar je weet nooit of je een reden vind.
-
Wat bedoel je met 'loopt er een VBA-project mee'? Er worden wel VBA-functies gebruikt in Excel door die standaard bij opstarten te openen. Maar ook een test-bestand waarin die functies niet gebruikt worden, heeft dit euvel.
Btw, xlsx heeft er geen last van.
is er niet iets veranderd in MS Office (een update of zo) die XLS bestanden meteen omzet naar XLSX (ik weet dat de webvariant dit bijvoorbeeld doet...)? Of loopt er een VBA project mee? Er móét toch een trigger zijn waarom het bestand verandert en daarmee gaat syncen...
-
Niet zelden hebben VBA-projecten wel invloed op of komen uit de main-template op basis waarvan het bestand dat je opent werkt.
Als er echter geen VBA-project in een testbestand zit en deze vertoont het sync euvel ook, dan zal dat het wel niet zijn hè...?
Ik weet dat (maar niet precies welke) er soms aardig wat komt kijken als het gaat om het verschil tussen de xls en xlsx en dan ook nog de versies van Excel zelf (zo heb ik er nu eentje die weigert CSV's goed importeren terwijl de xls Excel variant dat wel doet).
De vraag is dan toch: wát is er veranderd tov 'vroeger'. Ik kan me niet voorstellen dat dit aan de NAS-kant zit maar dat het toch echt binnen Excel gezocht moet worden. Misschien dat de compatibiliteitsmodus is aangepast?
Maar....waarom converteer je gewoon niet ieder bestand dat je toevallig opent of wijzigt. Dan is het toch opgelost? Vroeg of laat gaat xls er toch een keer uit en met xlsx krijg je wel nieuwe mogelijkheden erbij.
-
We hebben veel, heel veel xls-bestanden. Maar goed, het zou kunnen, alles converteren. Maar het ook belangrijk zijn te weten van welke datum het origineel is.