Slutsats: Felmönstret stämmer med SMB-kopiering med serveravlastning på samma server, inte med att en fil saknas
Kopieringen startar och når nästan 100 %, men sedan försöker Utforskaren igen och rapporterar att objektet inte längre kan hittas. Samtidigt fungerar det att flytta samma data i ZimaOS Filer. Den kombinationen pekar på SMB-överföringssökvägen mellan två utdelningar på samma server – inte på att källfilen har försvunnit.
Varför Windows hanterar SMB-kopieringar på samma server annorlunda
Windows kan begära en serverbaserad kopiering när källan och målet finns på samma SMB-server. Microsoft dokumenterar den här mekanismen som FSCTL_SRV_COPYCHUNK. Om den sökvägen inte hanteras korrekt kan Utforskaren misslyckas, även om vanlig läs- och skrivåtkomst till varje utdelning fungerar.
Använd en överföringssökväg som inte är beroende av Utforskarens optimering för kopiering på samma server
Tre praktiska alternativ:
- Flytta eller kopiera filerna i appen ZimaOS Filer.
- Kopiera Utdelning A till datorn och sedan från datorn till Utdelning B.
- Använd
robocopyoch verifiera målet.
Microsoft dokumenterar återförsök och kopieringsbeteende i referensen för robocopy.
Dra inte slutsatsen direkt att det handlar om behörigheter
Om du kan skapa, redigera och ta bort filer oberoende på båda utdelningarna är grundläggande autentiseringsuppgifter förmodligen inte den första felpunkten. Den aktuella hjälpdokumentationen för SMB i ZimaOS är rätt referens när en utdelning är skrivskyddad eller autentiseringsuppgifterna är felaktiga.
Vad vi kan och inte kan hävda
Fallet i communityn stämmer väl med ett kompatibilitetsproblem vid serverbaserad kopiering, men den aktuella offentliga manualen för ZimaOS dokumenterar inte beteendet för COPYCHUNK mellan utdelningar som en garanterad funktion. Se mönstret som en diagnostisk genväg, inte som en permanent plattformsetikett.
För normal konfiguration av fildelning, se guiden NAS 101 om fildelning och det autentiserade SMB-exemplet för ZimaOS.
