Copy error 0x80070299 naar een ReFS partitie

[ardvark99]

Hallo,

Ik heb afgelopen week mijn homeserver van nieuwe hardware voorzien, en ben nu bezig geweest om de data weer terug te zetten. Ik draai Windows 2019 Hyper-V core op mijn server, en heb een RAID5 die ik gebruik voor file opslag, geformatteerd met ReFS.

Nu heb ik ook een map met oude gedigitaliseerde video's die soms een bestands grote hebben van ongeveer 12-13 GB. Het aparte is dat de helft van deze bestanden probleemloos terug gekopieerd zijn naar de server, maar de andere helft geeft de volgende foutmelding na de kopieeractie:

Error 0x80070299: “The requested operation could not be completed due to a file system limitation”

Ik heb al op verschillende manieren geprobeerd de bestanden naar mijn server te kopiëren, bv via USB schijf.

Ik heb ondertussen begrepen dat er een stream gekoppeld kan zijn aan deze bestanden, pad en bestandsnaam zijn niet te lang, geen compressie, geen defragmentatie.

Hebben jullie eventueel ideeën die ik kan uitproberen?

[PD2JK]

Staan er vreemde NTFS permissions op die bestanden?
Encryptie, compressie of extended attributes op je bestanden van je bron?
Is je controller/storage in goede conditie evenals je usb disk?

[ardvark99]

PD2JK schreef op dinsdag 16 juni 2020 @ 22:17:
Staan er vreemde NTFS permissions op die bestanden?
Encryptie, compressie of extended attributes op je bestanden van je bron?
Is je controller/storage in goede conditie evenals je usb disk?

Nee, niets aparts. File is ready for archiving. Maar geen compressie of encryption. Het zijn avi files. In de proporties is niets aparts te zien.

Ik kan de files kopiëren naar NTFS partities op de server, maar niet naar ReFS partities. Een van die ReFS partities is gewoon een M.2 SSD, waar mijn VM's op staan. De RAID5 bestaat uit 4 3TB WD Reds, die ik dit weekend opnieuw gebuild en geformatteerd heb. Moederbord is een Asrock Rack E3C246D4U, en ik maak gebruik van de onboard controller. Wanneer ik de Intel Rapid Storage Technology Enterprise software opstart, geeft ie geen foutmeldingen of problemen. SMART geeft ook geen problemen.
En na de probleem bestanden heb ik gewoon nog andere mappen en bestanden kunnen kopiëren.
Al mijn overige data heb ik al over kunnen pompen naar de RAID, behalve de helft van mijn avi bestanden. Zoals gezegd, de andere helft is wel goed gegaan, de proporties zijn het zelfde.
En ik heb het op verschillende manieren geprobeerd, vanaf een PC waar ik ze tijdelijk naar toe had gekopieerd, en via USB disks.

[downtime]

ardvark99 schreef op dinsdag 16 juni 2020 @ 22:09:

Ik heb ondertussen begrepen dat er een stream gekoppeld kan zijn aan deze bestanden, pad en bestandsnaam zijn niet te lang, geen compressie, geen defragmentatie.

Heb je gecheckt of er echt een stream aan gekoppeld is?

[Anoniem: 11851]

Leuk dat je hypermodern wil zijn, maar ReFS heeft nog steeds behoorlijk wat limitaties:

Other features are still not supported on ReFS file system. Some of them are:

File encryption not supported (i.e.EFS)
File compression not supported
short names not supported
Hard links not supported
….

Ik zou zeggen, ga gewoon terug naar NTFS, om jezelf een berg gedoe, zoals dit, te besparen.

[ Voor 3% gewijzigd door Anoniem: 11851 op 17-06-2020 00:36 ]

[Trommelrem]

Robocopy of xcopy?
Default of backup mode?
Default of restartable mode?
Dats of Datsou?
LocalSystem al geprobeerd?
Draait je onderliggende VM wel NTFS?

[mkroes]

Hier iemand met het zelfde probleem. Bij hem had het te maken met een 'Alternate Data Stream'.
Hij komt met 2 oplossingen: eerste de bestanden naar een FAT32 partitie kopiëren (waardoor de NTFS metadata wordt verwijderd) en daarna door kopiëren, of via een (powershell) script. Dit script is ook te vinden via de link.

[ardvark99]

downtime schreef op woensdag 17 juni 2020 @ 00:00:
[...]

Heb je gecheckt of er echt een stream aan gekoppeld is?

Zover ik kan zien zijn er geen streams aan gekoppeld. Ik heb ook vanaf een andere locatie een steam gestart en gestopt, maar dit verandert niets.

[ardvark99]

Anoniem: 11851 schreef op woensdag 17 juni 2020 @ 00:24:
Leuk dat je hypermodern wil zijn, maar ReFS heeft nog steeds behoorlijk wat limitaties:


[...]


Ik zou zeggen, ga gewoon terug naar NTFS, om jezelf een berg gedoe, zoals dit, te besparen.

Dit is mij ook bekend. Maar ik heb ondertussen ongeveer 4TB gekopieerd, en alleen problemen met een 10 tal avi's. Ik zou geen tweaker zijn om eerst het probleem op te lossen. Terug naar NTFS kan altijd.
Ik heb thuis nog nooit ReFS gebruikt, maar met de nieuwe installatie, en doorlezen van diverse documentatie had ik zoiets als, toch eens proberen. Bovendien zijn er in Windows Server 2019 verbeteringen doorgevoerd.
Het probleem is niet zo zeer ReFS, maar er zit iets in de metadata van de bestanden dat ReFS niet zo leuk vindt.

[ardvark99]

Trommelrem schreef op woensdag 17 juni 2020 @ 06:55:
Robocopy of xcopy?
Default of backup mode?
Default of restartable mode?
Dats of Datsou?
LocalSystem al geprobeerd?
Draait je onderliggende VM wel NTFS?

De kopieer acties doe ik vanuit Hyper-V server. Ik heb ook geprobeerd om via een VM te kopieren. Naar een VM machine die NTFS is, lukt wel. Maar daarna weer naar ReFS gaat mis. De VM zijn op een aparte SSD geïnstalleerd, die ook ReFS geformatteerd is.
De bestanden zijn gewoon gekopieerd met File Explorer, niets aparts. Maar ik zou vanavond eens kunnen kijken met xcopy of andere suggesties.

[ardvark99]

mkroes schreef op woensdag 17 juni 2020 @ 07:36:
Hier iemand met het zelfde probleem. Bij hem had het te maken met een 'Alternate Data Stream'.
Hij komt met 2 oplossingen: eerste de bestanden naar een FAT32 partitie kopiëren (waardoor de NTFS metadata wordt verwijderd) en daarna door kopiëren, of via een (powershell) script. Dit script is ook te vinden via de link.

Kopiëren naar exFAT lukt in ieder geval niet, bestanden zijn te groot?

Die site heb ik gisteren ook gezien, alleen de topic starter heeft idd wat scripting toegevoegd, daar heb ik overheen gelezen, ik had meer de comments doorgelezen. Vandaar dat ik iets had gezien over streams.

Maar ik zal de powershell scripts vanavond ff uitvoeren. Misschien is dit idd toch de oplossing. Thanks.

[downtime]

ardvark99 schreef op woensdag 17 juni 2020 @ 11:00:
[...]

Zover ik kan zien zijn er geen streams aan gekoppeld. Ik heb ook vanaf een andere locatie een steam gestart en gestopt, maar dit verandert niets.

Het klinkt alsof je niet weet wat een stream (officieel Alternate Data Stream) in NTFS is.

Probeer het hier eens mee: https://docs.microsoft.co...ternals/downloads/streams

ardvark99 schreef op woensdag 17 juni 2020 @ 11:21:
[...]

Kopiëren naar exFAT lukt in ieder geval niet, bestanden zijn te groot?

Ja, dat gaat nooit lukken met exFAT of FAT32.

[Brahiewahiewa]

ardvark99 schreef op woensdag 17 juni 2020 @ 11:21:
[...]

Kopiëren naar exFAT lukt in ieder geval niet, bestanden zijn te groot?

Ja, zowel voor exFAT als voor FAT32 is de max file size 4GB

Die site heb ik gisteren ook gezien, alleen de topic starter heeft idd wat scripting toegevoegd, daar heb ik overheen gelezen, ik had meer de comments doorgelezen. Vandaar dat ik iets had gezien over streams.

Maar ik zal de powershell scripts vanavond ff uitvoeren. Misschien is dit idd toch de oplossing. Thanks.

Ik zou effe kijken welke ADS er aan hangt; je kunt ze ook verwijderen namelijk. Een ADS van je virus scanner uit 2014 ben je toch niet in geïnteresseerd

[downtime]

Brahiewahiewa schreef op woensdag 17 juni 2020 @ 13:57:

[...]

Ik zou effe kijken welke ADS er aan hangt; je kunt ze ook verwijderen namelijk. Een ADS van je virus scanner uit 2014 ben je toch niet in geïnteresseerd

Strict genomen bevat elke file een ADS. Meestal is dat de default stream die de data van de file bevat. Extra streams kun je in 99 van de 100 gevallen gewoon verwijderen.
De belangrijkste toepassing die ik ken is voor browsers die bij een download in een aparte stream informatie over de oorsprong van een bestand zetten. Dat zorgt dan weer voor de security popup als je een bestand wilt uitvoeren wat van een website komt en niet van een certificaat is voorzien.

[Henk007]

Brahiewahiewa schreef op woensdag 17 juni 2020 @ 13:57:
[...]
Ja, zowel voor exFAT als voor FAT32 is de max file size 4GB

downtime schreef op woensdag 17 juni 2020 @ 13:56:
Ja, dat gaat nooit lukken met exFAT of FAT32.

Niet correct, exFat heeft een file size limit die way boven huidige capaciteiten van opslagmedia ligt. (2⁶⁴ -1 bytes)

[ardvark99]

Even een update:
Ik heb een aantal files kunnen aanpassen met de powershell commando's (@mkroes bedankt voor de tip);

get-item <filename> -stream * | select Stream,Length
remove-item <filename> -stream <stream name>
clear-content <filename> -stream <stream name>
get-content <filename> -stream <stream name>

Daarbij waren er een paar met een <:$DATA> en <TOC.WMV> streams. Die laatste(Windows Media player of zo?) heb ik verwijderd, en daarna kon ik de avi bestanden wel verplaatsen naar de ReFS schijf.

Maar de andere bestanden gaven geen streams, dus ik heb nogmaals geprobeerd om met een exFat (Allocation Unit Size op 4096 kilobytes gezet) geformatteerde USB schijf de overgebleven bestanden te kopiëren. Kopieer actie gestart met xcopy /j. Nu werden de bestanden wel gekopieerd (nu nog bezig...) en vandaaruit 1 bestand weer naar de ReFS schijf. Dit ging goed. @Henk007, nu gaat het dus wel.

En @downtime , ik kende ADS idd nog niet, inmiddels wel, leer toch telkens wat bij ;-) Ik ben dus ook nooit tegen dit probleem aangelopen.

Maar tot zover, iedereen bedankt voor het mee denken. Morgen eens kijken of alles op zijn plek staat, en ook weer afspeelbaar is. Ik zal morgenavond nog een update plaatsen.

[ardvark99]

Laatste update: Alle files staan nu op de RAID5 ReFS, en gechecked, de avi's spelen af zoals het hoort.
Ik heb nog ff een aantal dingen getest om te kijken waar het o.a. op mis gegaan is. Vanuit de GUI file explorer op mijn Hyper-V machine lukt het dus niet om grote bestanden naar de USB disk te kopieeren, exFat geformatteerd. Met xcopy lukt dit dus wel. En de AUS van exFat maakt dus niet uit. In eerste instantie had ik xcopy nog niet geprobeerd, maar na een opmerking van @Trommelrem heb ik dit toch geprobeerd.

Ik heb dus 2 files kunnen fixen met powershell, maar nadat bleek dat de andere files geen ADS streams hadden, ben ik verder gegaaan met xcopy. Vermoedelijk had ik een hoop ellende betreffende dit probleem kunnen besparen, door gelijk met xcopy aan de gang te gaan. Niet dat ik xcopy niet ken, ben opgegroeid in het DOS tijdperk, maar door jaren weinig probleemloos gebruik van File Explorer ga je andere oplossingen vergeten.
Nogmaals, iedereen bedankt voor het meedenken, nu kan ik weer verder met het opnieuw inrichten van mijn server, nu alle files weer op hun plek staan.

BTW, ik kan maar 1 beste antwoord geven, maar voorr mij waren er meer beste antwoorden

[ Voor 4% gewijzigd door ardvark99 op 18-06-2020 21:15 ]