A diferença com sudo pode ser devido ao extrato abaixo de Documentation / filesystems / vfat.txt . (Requer conhecimento de que seu sistema de arquivos de destino é do tipo vfat & que possui o diretório ^ Wfilesystem - determinado pela opção mount no caso de vfat ).
Eu fui em frente e postei isso de qualquer maneira porque mostra o quão importante são os tipos de sistema de arquivos. A conclusão geral foi que usando FAT no Linux é dor (e lá foi um problema especial com o rsync no FAT também) .
Tenho certeza de que pelo menos um dos problemas listados foi resolvido com padrões diferentes (possivelmente em udisks como usado pela GUI, ao contrário dos comandos manuais mount ). Em qualquer caso, sugiro que você esteja perdendo seu tempo se o que você está tentando fazer é copiar partes do seu sistema operacional Linux para o FAT, e você exige resultados específicos em metadados de arquivos (timestamps), ou até nomes de arquivos. Nesse caso, você deve usar um sistema de arquivos Linux nativo, idealmente do mesmo tipo que a fonte.
Ou, em vez de copiar arquivos individuais, crie um arquivo usando uma ferramenta nativa do Linux, como tar . Pense no arquivo Zip - mas especificamente projetado para fazer backup de arquivos tar -c -f out.tar input-directory/ (omite a compactação).
Documento de referência para configurar registros de data e hora FAT no Linux
allow_utime=### -- This option controls the permission check of mtime/atime.
20 - If current process is in group of file's group ID,
you can change timestamp.
2 - Other users can change timestamp.
The default is set from 'dmask' option. (If the directory is
writable, utime(2) is also allowed. I.e. ~dmask & 022)
Normally utime(2) checks current process is owner of
the file, or it has CAP_FOWNER capability. But FAT
filesystem doesn't have uid/gid on disk, so normal
check is too unflexible. With this option you can
relax it.
Confirmação da comunidade e outros possíveis problemas para evitar
Então, a postagem do blog que encontrei confirma msgstr "apenas o dono de uma montagem FAT32 pode definir registros de horário de arquivo". Eu chamaria isso de bug de design (o root também deveria ser capaz de fazer isso), que a documentação de referência quase soletra, mas eu estou com preguiça de enviar um patch para ele.
O blog também fornece uma explicação para uma diferença de arquivo / diretório. Infelizmente, parece ser duplamente oposto ao que você descreve. Eu acho que a diferença de arquivo / diretório descrita abaixo deveria ter impedido seu usuário normal de configurar timestamps corretamente em diretórios - enquanto o que você mostrou é que se você for root , você pode definir os timestamps corretos nos diretórios, mas não nos arquivos.
Parece-me que o --modify-window=1 é uma solução para um problema específico do rsync. Portanto, usar cp para copiar arquivos pode fornecer outro ponto de dados.
Even the owner of a FAT32 mount can't set directory times reliably
Although I was now able to copy over the original file time stamps correctly I noticed that all of the directory modification times were set to the time I ran the rsync command, which is not what I wanted at all. A little googling uncovered this forum posting about this problem: http://ubuntuforums.org/showthread.php?t=886048
This forum posting suggested adding the option "--modify-window=1", which gives 1 second slack on how closely file and directory times have to match before rsync will see them as different, and someone said that worked to correctly preserve original directory timestamps.