Synology-Forum.nl
Firmware => Synology DSM algemeen => Topic gestart door: pjottervmr op 09 juni 2015, 20:55:31
-
IK heb een vreemd probleem met data bestanden die ik copieer op de nas en daarna wil lezen met een MSDOS machine.
Het bestand heet bv: 179731.jpg en moet van een bepaalde map gekopieerd worden naar een andere map. Na het kopiëren naar die map is de naam aangepast als ik hem wil ophalen met de MSDOS machine. De nieuwe naam is dan bv 17973~Y6 en er is geen logica in te ontdekken.
-
Misschien kan je van dit (https://support.microsoft.com/en-us/kb/142982?wa=wsignin1.0)wijzer worden. ;)
-
502 Bad gateway ?
Sent from my iPad using Tapatalk
-
Hier niet hoor, link is goed:
[attachimg=1]
-
Misschien kan je van dit (https://support.microsoft.com/en-us/kb/142982?wa=wsignin1.0)wijzer worden. ;)
Ik kom uit de tijd van dos dus de 8.3 regel die ken ik en dat is niet het geval hier de namen zijn max 8.3 karakters.
Ik kopiëren met windows 7 de bestanden en vandaag is het probleem niet voorgekomen.
-
502 Bad gateway ?
Bad gateway is alleen met HTTP dacht ik? Ik kopieer gewoon met windows 7
-
Hier niet hoor, link is goed:
Ik weet van de 8.3 regel van dos uit. IK ga nu echter twijfelen wat ik nu gedaan heb met het kopiëren? Ga nu twijfelen of er een fout in de landen instelling is. Ik heb het vandaag niet meer gehad dus twijfel er nu aan. Kan me voorstellen dat degene mac de punt ziet en de andere die als komma herkent dat is volgens mij de enige manier waarom het zou kunnen voorkomen dat de 8.3 regel fout gaat. (met een komma ziet dos dus 12 karakters ipv 8.3?
-
De opmerking over gateway en de link gingen over de link die door flingle gepost was. Had dus niets met jouw probleem te maken.
Het probleem is dat Windows 7 van lange filenamen gebruik maakt. Ook al zijn de namen van de files dan in 8.3 formaat, bij het kopiëren worden ze door Windows 7 toch behandeld als lange filenamen. En dan krijg je op je MS-DOS machine de door Windows 7 op de achtergrond aangemaakte bijbehorende korte filenaam te zien.
-
Ok dan toch vreemd dat dit dus tijdens het kopiëre omgezet wordt? Ik heb vandaag dat probleem niet gehad en nog nooit gehad dus vreemd? De naam wordt gemaakt en weggeschreven in windows 7 en wordt ingelezen door een dos machine nooit problemen gehad. Alleen dus bij het kopiëren die fout 1 dag ik denk dan dat dit toch niet aan windows 7 ligt maar eerder aan zoiets als de landinstellingen zodat de komma en de punt verkeerd worden gezien. LAs het altijd aan windows lag had ik er eerder last van moeten hebben volgens mij?
-
Dit heeft in ieder geval niets met conversie van lange filenamen naar 8.3 Dos namen te maken.
Ik denk eerder dat het iets met verkeerde code pages te maken heeft of dat er ergens utf8 namen gebruikt zijn en dat ondersteund Dos niet.
Als de bestanden van een mac komen zal dat wel het probleem zijn.
-
Dit heeft in ieder geval niets met conversie van lange filenamen naar 8.3 Dos namen te maken.
Ik denk eerder dat het iets met verkeerde code pages te maken heeft of dat er ergens utf8 namen gebruikt zijn en dat ondersteund Dos niet.
Als de bestanden van een mac komen zal dat wel het probleem zijn.
De bestanden komen niet van een MAC en ze worden gemaakt door windows 7 computers en de namen zijn volgens het principe 8.3 daar ligt het probleem niet. Het kwam nadat ik bestanden op de NAS van de ene map naar een andere map heb gekopieerd met behulp van een windows 7 computer. Dus windows 7 schrijft het bestand op de NAS met 8.3 in dit geval bijna altijd 6 nummers en eventueel _D of _M.
De dos machine kan die bestanden prima inlezen geeft geen enkel probleem. Nu moeten de bestanden naar een andere map en daarom met behulp van windows 7 die bestanden gekopieerd en toen ontstond het probleem.
Vervelende is nu dat dit vandaag dus niet gebeurde en daarom ga ik volgende week proberen dit probleem te produceren door met verschillende systemen te kopiëren.
-
Ik zou toch even de code page settings van zowel je windows machine als je Nas controleren.
Als daar een mismatch in zit kun je rare verschijnselen krijgen.
-
Dat is hetgeen ik dan meteen zie welke machine dit probleem veroorzaakt.
Heeft 7 maanden gewerkt zonder problemen dus zal iets bijzonders zijn :D
-
Ik weet inmiddels meer en het heeft inderdaad met de 8.3 te maken (mangling options). Probleem is het volgende:
Programma zet bestand weg in een bepaalde naam.extensie. Als de naam niet aan 8.3 voldoet heb je een probleem dat is duidelijk op een MSdos computer. Het probleem is echter ook als de naam wel voldoet aan die norm van 8.3.
Copieer ik dat bestand naar een andere map dan ziet het er op windows 7 computers en op de NAS gewoon goed uit. Als ik echter met de MSDOS computer kijk dan zitten er fouten in het bestand Probleem doet zich echter niet voor als ik vanaf de NAS met windows 7 het bestand kopieer naar een MSDOS flop dan is het bestand prima in te lezen op de MSDOS computer. Probleem zit dus niet in Windows 7 maar dus echt op de NAS waar bij onderling kopiëren er iets wordt aangepast zodat het er anders uitziet op een MSDOS computer.
-
Bedankt voor de terugkoppeling.
-
Het zit iets anders in elkaar.
Op een smb share heeft (net als op windows) twee filenamen, te weten een Long File Name en een DOS 8.3 filename.
Je kunt de gebruikte DOS namen zien door onder windows met een command prompt het commando dir /x te geven, dan zie je beide namen.
Op het moment dat een filenaam niet kan voldoen aan het 8.3 formaat zal een afgeleidde van dat 8.3 formaat in dat DOS naamveld geschreven worden.
Voldoet de filenaam wel aan dat 8.3 formaat dan zal dat DOS naamveld leeg blijven.
De vreemde namen die jij ziet ontstaan doordat linux een andere methode voor het converteren van Lange Filename naar DOS namen heeft dan Windows.
Dat aanmaken van die DOS 8.3 naam gebeurd echter alleen als de lange filenaam niet aan de 8.3 standaard voldoet en het DOS filename veld leeg is.
Voldoet hij daar wel aan dan zal dat DOS 8.3 veld leeg blijven.
Dus als jij vreemde filenamen ziet dat zijn ze waarschijnlijk aangemaakt door je NAS omdat onderweg ergens de long file name niet meer aan de 8.3 norm voldeed en dus er een DOS 8.3 filename bijgezet werd.
-
Ok duidelijk en dit verhaal had ik zelf ook al bedacht helaas :D.
Ik begrijp dan niet dat de naam met : 123456_K.jpg na kopiëren naar een andere map gewoon in de NAS of op windows 123456_K.jpg heet en als ik dan vanuit dos naar die nieuwe map ga het bestaan dan 1234~ua heet......
-
Dat lijkt me nogal voor de hand liggend.
Het veld voor de DOS naam blijft leeg bij kopieer actie door windows of door de NAS en zie je alleen de Long File Name.
Als je met DOS gaat benaderen dan maakt DOS die naam aan en zie je in DOS alleen de naam die door DOS is aangemaakt en niet de Long File Name.
Als je in windows een command prompt maakt kun je met Dir /x beide namen zien en kun je volgen hoe het werkt.
-
Nee dat is niet wat ik zeg volgens mij?
Ik kopieer met windows 7 het bestand van de ene map naar de andere map en met windows 7 ziet het er dan gewoon goed uit. (123456_K.jpg) Het voldoet aan de norm 8.3 , als ik dan met de MSdos machine kijk ziet het er zo uit 1234~AI.
k kopieer niet met DOS dat is niet het geval.
-
Maakt niet uit of DOS wel of niet kopieerd.
Op het moment dat je met DOS kijkt vult die het DOS veld.
Of beter gezegd de netwerk stack vult dat DOS veld, want DOS zelf ziet alleen dat DOS veld en dat was daarvoor nog leeg.
Als je daarna weer met windows kijkt ziet die dat het DOS veld verandert is en kopieerd dat naar het Long File Name veld.
-
Ok dan is dat kopiëren me duidelijk dacht dat je bedoelde dat ik met Dos kopieerde.
Ik kijk nu via windows en via de command prompt van windows en ik zie inderdaad het verschil nu voor de lange namen maar dat die verminkt worden dat was me al lang duidelijk zelfs voor ik de vraag hier stelde. Het gaat met name om de namen die voldoen aan de 8.3 standaard en die worden soms ook verminkt en dat begrijp ik niet. Moet toch iets zijn wat ik dus niet zie in de namen zal er van de week eens goed naar kijken.
-
Het is toch heel simpel hoor.
Linux heeft een andere methode om die DOS naam aan te maken dan windows.
Aangezien je vanuit Dos het bestand aanspreekt, zal de netwerkstack van linux dat Dos veld vullen dat eerst leeg was.
Dat doet hij volgens de linux standaard
Dos kan dat natuurlijk niet want die kan die Long File Name helemaal niet zien.
Doe maar eens een test, maak met bijvoorbeeld windows notepad een bestand aan op een share van je Nas.
Kijk met dir /x hoe dat eruit ziet.
Bekijk hem daarna eens vanuit die Dos machine en vervolgens nog eens met dir /x.
Herhaal dat nogmaals maar maak dat bestand niet op je Nas aan maar op een windows drive en je ziet het verschil.
-
Misschien heb je iets aan dit artikel.
http://www.oreilly.com/openbook/samba/book/ch05_04.html
-
Ik ben vandaag weer lekker bezig geweest met de NAS en weer wat meer info verzameld van dit probleem.
Probleem blijkt niet in de short name of long name te zitten. Natuurlijk is de lange naam een probleem voor MSDOS en wordt die naam afgekort. Probleem zit echter ook in korte namen. Een naam als Thee3.cf2 wordt via MSDOS ingelezen als thee3`IA
Ook alle andere bestanden die voldoen aan de 8.3 naam geving worden verkeerd ingelezen op de MSDOS machine.
Ik heb met de command promt gekeken (zoals Ben V al aangaf) via de windows 7 en dan zie je keurig dat er geen dos veld wordt gevuld.
Een voorbeeld is 123456AA.cf2 en 123456AAA.cf2 De laatste ziet er dus in het dos venster uit als 1glk`w.cf2 en bij de eerste is het dos veld leeg. Dit is allemaal logisch en dus ook voor mij begrijpbaar. :D
Nu dus dat bestand met 123456AA.cf2 dat volgens de tegels is gemaakt en voldoet aan die 8.3 standaard voor MSDOS, dat ziet er als ik met de MSDOS machine naar kijk uit als 1RC2AH`X.cf2 als ik echter het bestand van de NAS kopieer naar een floppy en die inlees met de MSDOS machine dan ziet het er goed uit als 123456AA.cf2.
Waar moet nu eea worden aangepast zodat de namen goed worden weergegeven?
Ik werk met de MSDOS machine met een NFS client dus gebruik geen smb De map waar de bestanden staan is open voor iedereen (everyone)
-
Blijkbaar is lezen vrij moeilijk!!!
Je krijgt op die manier de linux conversie omdat het DOS veld leeg is en dat wordt dan gevuld door in dit geval Samba (dus linux).
Dos kan dat niet vullen of lezen want die ziet die Long File Names niet.
Op elke windows machine staat een utitlity fsutil waar je die DOS name zelf mee kunt zetten in een commandvenster of een commandfile.
Het format is:
fsutil file setshortname <FileName> <ShortName>
Als je nu een batch programmaatje maakt die je FileName kopieerd naar ShortName en dit vanuit een windows machine draait, dan wordt op dat moment die short filename gevuld en zal linux er verder vanaf blijven.
EDIT:
Als je niet weet hoe je zo'n batch bestandje moet maken dan kun je onderstaand in een .bat bestandje zetten en vanuit de command prompt uitvoeren.
Alle bestanden in de folder waar je dan staat worden dan van een shortfilename voorzien.
Het gaat er wel van uit dat de Long FileNAme al in een 8.3 formaat staat anders gaat het mis.
@echo off
SETLOCAL ENABLEDELAYEDEXPANSION
for /f "tokens=*" %%f in ('dir /b *.*') do (
fsutil file setshortname %%f %%f
)
-
Ok lezen is blijkbaar moeilijk maar met nalezen van dit topic kon ik deze info niet terug vinden :D
Of het moet zijn dat je aangeeft dat de naam onderweg niet aan de 8.3 voldoet.
Als je dat bedoelt begrijp ik dit niet omdat de naam juist aan voldoet? Sterker nog zodra windows meteen een bestand in de juiste map wegzet dan voldoet die prima aan de 8.3 norm en kan ik deze nog steeds niet inlezen op de MSDOS computer. Ik mag er toch vanuit gaan dat als de naam voldoet aan de norm 8.3 bij het plaatsen van het bestand op de NAS deze dan meteen goed geplaatst wordt?
-
Nee daar mag je niet vanuit gaan.
Er zijn op disk gewoon twee velden aanwezig.
Een voor de LongFileName en een voor de DOSname.
Als het bestand met windows of linux wordt aangemaakt dan wordt alleen het veld met de LongFileName gevuld en het DOS veld blijft leeg.
Als je dan dat bestand wilt bekijken met DOS wordt op dat moment door de fileserver (in dit geval je NAS) dat DOS veld gevuld.
Zorg je er echter zelf voor (met fsutil) dat het DOS veld wel gevuld is dan zal de fileserver niets meer met dat DOS veld doen, want het is al gevuld.
-
Ok nu is het me duidelijk alleen niet makkelijk om te realiseren omdat minimaal elke 30 minuten wel nieuwe bestanden naar de NAS worden geschreven. Eigenlijk zou dan elke keer na het wegschrijven van het bestand dat bat bestandje moeten worden gestart omdat die bestanden vrij snel na aanmaken moeten worden ingelezen door de MSDOS computer.
Weer bedankt voor je uitgebreide info en ik weet weer even voldoende en ga er verder. Het het verplicht vullen van het shorname field zou je dan eigenlijk meteen moeten kunnen doen vanuit het tekenprogramma op de windows machine of in de instellingen van de NAS.
Ik ben naar de NAS als file server overgestapt vanuit een Linux computer die als data server draaide en dacht dat de oplossing zou zijn :D
-
wat ik me net bedenk is zou het aansluiten van een MSDOS partitie met vFat indeling een optie of zijn?
Kijk ik naar de Floppy die nu gebruikt wordt als oplossing dan denk ik dat het rechtstreeks aansluiten van een USB stick met vFAT geformatteerd toch dan moet werken of zie ik dit verkeerd? Er is dan geen linux of NTFS file systeem voor het opslaan van lange namen?
-
Je kunt het proberen maar ik weet niet of het gaat werken.
Wat vFat doet is meerdere directory entries gebruiken voor lange filenamen om zo compatible te zijn met windows.
Ik weet niet of je zo ook twee naamvelden creeeren of dat dit alleen gebeurt als de naam te lang is.
Je kunt het dus proberen.
Ben benieuwd.
-
Ben even bezig geweest met een usb stick en die als VFAT geformatteerd maar daar heb ik geen uitsluitsel van. Met windows 7 zie je gewoon met Dir/x hetzelfde. Ga dit wel proberen met de MSDOS computer want in principe zou dit moeten werken?
Nu copieren het bestand vanaf de NAS naar een externe usb floppy mbv windows 7 en vervolgens laden we de flop in de MSDOS computer.
Zodra ik meer weet laat ik het weten maar in simpel redeneren zou ik zeggen dat dit zou moeten werken? Moet alleen ook nagaan of het verschil uitmaakt of de externe USB flop aan de NAS of aan de windows moet zitten? Als dat niet uitmaakt dan zou een externe USB stick van 32 mb dit ook moeten ondersteunen.
-
Als je met DIR /x hetzelfde ziet gaat het vast niet werken.
Even samenvattend voor zover ik je begrepen heb.
Je maakt met een windows machine een bestand aan met een bepaalt programma.
En je wilt dat bestand inlezen in een DOS machine.
LAten we dat programma even AppX noemen.
Draait AppX continue en maakt hij regelmatig een bestand aan of wordt AppX ergens door opgestart?
Als dat laatste het geval is zou je in het batch programmaatje dat ik je gegeven heb als eerste AppX laten uitvoeren en daarna de rest.
Zo wordt elek keer de DOSnaam toegevoegd.
Als dat niet zo werkt zou je kunnen overwegen een loop in het batchprogrammaatje te maken en hem gewoon om de zoveel tijd een rondje te laten maken.
-
AppX in het bat bestandje zetten lukt niet appX vanaf begin van de werkdag aan staat en wordt gebruikt.
Het bat bestandje om de zoveel tijd runnen is ook geen optie of je moet dit om de 10 minuten doen ik begrijp dat dit opties zijn maar dan ga ik liever gewoon om en ga ik voor een linux server zoals die voordien was voor die bestanden. Ik ga het eerst eens van de week weer bekijken en met de externe flop proberen.
-
Je kunt toch gewoon een loop in dat batch progje maken die om de 10 minuten een rondje doet en dan weer 10 minuten wacht
-
Dat kan inderdaad alleen dan moet de man aan de machine weer wachten als hij het bestand niet ziet tot dat het is bijgewerkt. Dat is niet de bedoeling. Dan kan ik het om de 5 minuten zetten enz enz maar dat is niet wat de oplossing is helaas.IK moet nog wel proberen of het met het bat bestandje is opgelost omdat ik dit alleen op de lokale machine kan draaien. Nu heb ik het geprobeerd maar worden alleen de lange namen geforceerd neergezet. fsulil werkt alleen op een Local NTFS volume.
-
Inmiddels na bijna 2 maanden proberen samen met Synology zijn we er uit gekomen en hebben ze via teamviewer meegekeken naar het probleem. Blijkt te maken te hebben met default case die moet op lower staan.
Nadat eea is aangepast werkt het nu prima zonder batch bestand of wat dan ook. Wegschrijven naar de NAS geeft elke keer indien men zich houd aan de 8.3 naamgeving geen problemen. Met dank aan Synology zelf waarbij de developers dit na enkele weken testen en proberen nu vandaag voor elkaar hebben gekregen.Was een project met lange adem maar het is nu verholpen :D
-
Mooi dat het is opgelost maar, wat bedoel je precies met:
Blijkt te maken te hebben met default case die moet op lower staan.
-
Men heeft het smb.conf bestand aangepast:
1 men heeft unix charset =ASCII
2 men heeft default case = lower
3 men heeft preseserve case - no
4 men heeft short preserve case = no
De laatste 3 regels zorgen er voor dat een bepaald programma wat ik gebruik ook leesbare name wegschrijft op de nas. NU deed ik dit door eerst naar een linux computer te saven en dan te kopiëren naar de nas. Nu werkt alles meteen, hulde aan ruim 2 maanden ploeteren van Synology :-)