`sudo cp -a` cambia la proprietà in root (invece di preservare l'utente originale)

Stavo provando a fare il backup di alcune directory e alcune delle copie fatte da sudo cp -avrisultavano essere di proprietà di root mentre altre conservavano i loro attributi. È un problema noto o mi sto perdendo qualcosa?

Il sorgente (ext4) è un ex disco di sistema ubuntu usato esternamente, la struttura della directory è intatta ma è usata solo per l'archiviazione, non per l'avvio. Il nome utente / nome gruppo e uid / gid sono gli stessi del sistema precedente.

La destinazione (btrfs) formattata da NTFS, usando i 4.1.2 btrfs-progs.

$ sudo cp -av /mnt/src/home/user/thecakeisalie/ /mnt/dest/subvol/

drwx------ 6 user user 4096 Jul 18 09:11 /mnt/src/home/user/thecakeisalie/
drwx------ 3 root root 4096 Jul 18 20:36 /mnt/dest/subvol/thecakeisalie/

  File: ‘/mnt/src/home/user/thecakeisalie/’
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 812h/2066d  Inode: 9044504     Links: 6
Access: (0700/drwx------)  Uid: ( 1000/user)   Gid: ( 1000/user)
Access: 2015-07-18 20:21:08.725414953 -0700
Modify: 2015-07-18 09:11:06.873427304 -0700
Change: 2015-07-18 20:08:34.161737231 -0700
 Birth: -

  File: ‘/mnt/dest/subvol/thecakeisalie/’
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 805h/2053d  Inode: 660098      Links: 3
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-07-18 20:36:23.909377491 -0700
Modify: 2015-07-18 20:36:09.729089386 -0700
Change: 2015-07-18 20:36:09.729089386 -0700
 Birth: -

Testare alcune altre directory sotto ha /mnt/src/home/user/thecakeisalie/comportato il comportamento previsto con ls -l, statoutput esattamente corrispondenti.

Alcune directory "ben comportanti" sono state create questo pomeriggio, ma ho provato questo su quelli che non sono stati toccati molto prima di iniziare a utilizzare l'unità esternamente e alcuni di loro sono ok.

Dopo il backup ho eseguito chowntutto, quindi non c'è problema, ma sono davvero curioso di sapere quale potrebbe essere la causa. Ho cercato su Google molto ma non stavo usando la frase di ricerca giusta o questo è ben noto.

mjturner qui sotto aveva un punto, quindi ho provato i cp -acomandi per la mia ~/Downloaddirectory sul disco di sistema interno (ext4) e i risultati sono gli stessi, quindi non penso che sia un problema di btrfs.

La settimana scorsa ho sistemato un vecchio laptop in cui le circostanze erano simili: per aggiornare Ubuntu 13.10 ho dovuto installare Ubuntu 15.04 su un'altra nuova partizione e dopo l'avvio ho fatto sudo cp -al'intera casa dal vecchio sistema. 13.10 avevano 2 utenti (alfa, bravo) e 15.04 erano stati impostati con 1 utente (alfa). Le voci di bravo hanno finito per mostrare il GID / UID (ovviamente) mentre quelli di alpha sembravano e funzionavano come prima. (Devo verificare se il GID / UID della vecchia e della nuova alfa sono uguali).

Alcune informazioni extra sul sistema attuale, uname:
Linux 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:14:22 UTC 2015 i686

Ho intenzione di fare un grosso clean-up sull'unità sorgente (eliminando le directory di sistema e spostando le directory di archiviazione principali nella radice) e testerò di nuovo.

Nel frattempo, ci sono altri comandi che posso usare per testare l'origine e la destinazione per le differenze? Non importa quanto in basso devo scavare (volevo comunque rispolverare C).

Mi sono reso conto che ho dimenticato di dire che ho interrotto cp -adopo aver verificato la destinazione in un altro terminale mentre stavo copiando oltre 300 GB di dati.

Grazie al commento di Gilles ho iniziato i test per vedere se succede solo alle directory. Come dimostrano i test di seguito, praticamente tutti i file vengono scritti come root e i vecchi attributi vengono applicati al file / directory al termine della copia.

TEST_1: cartella da 3 GB e CTRL-C durante sudo cp -a: il file corrente viene troncato, lasciato come root e così è la directory.

home/Download# ls -l
total 20
drwx------ 3 root      root       4096 Jul 19 15:11 ./
drwxr-xr-x 3 user user 12288 Jul 19 15:11 ../
drwx------ 2 root      root       4096 Jul 19 15:11 thecakeisalie/

home/Download# cd thecakeisalie/; ls -l
total 16164
drwx------ 2 root      root         4096 Jul 19 15:11 ./
drwx------ 3 root      root         4096 Jul 19 15:11 ../
-rw------- 1 user user 2109623 May 19  2013 file1
-rw------- 1 user user 2520465 May 19  2013 file2
-rw------- 1 root root 393216  Jul 19 15:11 file3

TEST_2: consenti sudo cp -adi terminare:

home/Download# ls -l
total 20
drwx------ 3 user user  4096 Jul 19 15:11 ./
drwxr-xr-x 3 user user 12288 Jul 19 15:11 ../
drwx------ 2 user user  4096 Jul 19 15:11 thecakeisalie/

home/Download# cd thecakeisalie/; ls -l
total 16164
drwx------ 3 user user  4096 Jul 19 15:11 ./
drwxr-xr-x 3 user user 12288 Jul 19 15:11 ../
-rw------- 1 user user 2109623 May 19  2013 file1
(...)
-rw------- 1 user user 2520465 May 19  2013 last_file

Che sembra molto strano per me - quello che hai descritto è sicuramente non è un problema noto. Ho usato cp -aampiamente (anche per clonare interi sistemi Linux) e l'unica volta che ho visto un problema, è stato causato da un bug in XFS (che è stato successivamente risolto).

La mia ipotesi è che si tratti di un bug btrfs, che è ancora in fase di ampio sviluppo. È riproducibile? Puoi provare a copiare quelle stesse directory di origine in una nuova posizione sul tuo filesystem di destinazione e vedere se le autorizzazioni sono conservate. Se è riproducibile, è possibile presentare una segnalazione di bug .