Renommage en masse fichier

Jean-paul 3 · Le 10/07/2019, à 17:02

Bonjour,

J'aimerai pouvoir renommer en masse des fichiers exportés à la volée par un système tierce.

Les fichiers sont exportés sous la forme :
123456/458721/65231475/875584213.txt
85468/64237876/464/423.txt
7458125/45824/421/8564213/66584621.txt
……..

En fait ce qui m'importe c'est de pouvoir renommer en masse pour ne garder que ce qui se trouve derrière le dernier / puisqu'il s'agit du nom du fichier.
Ce qui est devant ce dernier slash peut être aléatoire et ne m’intéresse pas, il s'agit du chemin du fichier.
En clair, je voudrais pouvoir renommer en masse par script pour que les fichiers perdent le chemin dans leurs noms et ne se nomment plus que, par exemple, sur l'exemple ci-dessus :
875584213.txt
423.txt
66584621.txt

Si quelqu'un à un petit script à me proposer,
D'avance merci

Watael · Le 10/07/2019, à 17:09

salut,

mais les noms de fichiers ne peuvent contenir de slashes, donc tu ne peux pas renommer de tels fichiers, puisqu'ils ne peuvent pas exister !

erresse · Le 10/07/2019, à 17:13

Jean-paul 3 a écrit :

Ce qui est devant ce dernier slash peut être aléatoire et ne m’intéresse pas, il s'agit du chemin du fichier.

Petit problème : même si ces informations ne t'intéressent pas (c'est ton choix), elles sont toutefois essentielles pour parvenir jusqu'au fichier lui-même qui t'intéresse...
Si ce(s) chemin(s) peu(ven)t être n'importe quoi, il faudrait que le script scrute toute l'arborescence de ton système pour trouver ces fichiers.
Tu n'aurais pas quand même une idée de ce qui constitue ce(s) chemin(s) pour limiter un peu les dégâts ?

cqfd93 · Le 10/07/2019, à 18:29

Bonjour,

Il y a sûrement moyen de faire quelque chose avec basename et dirname :

moi@aurore:~$ basename -s .txt 123456/458721/65231475/875584213.txt
875584213
moi@aurore:~$ dirname 123456/458721/65231475/875584213.txt
123456/458721/65231475
moi@aurore:~$

Watael · Le 10/07/2019, à 18:36

oui, ces commandes externes peuvent utiles dans un shell strictement POSIX; en bash (au moins), le Développement de paramètres fait des choses équivalentes.

pour ma part, j'ai un problème avec l'exposé fait par Jean-paul_3.

cqfd93 · Le 10/07/2019, à 18:42

Watael a écrit :

pour ma part, j'ai un problème avec l'exposé fait par Jean-paul_3.

oui, c'est flou, il faudrait en savoir beaucoup plus sur le contexte.

nam1962 · Le 10/07/2019, à 18:50

Il serait effectivement intéressant de préciser le répertoire le plus haut où ça arrive, si la date est connue.
mtime ou ctime peuvent alors servir : https://askubuntu.com/questions/532329/ … te-created
On ne sait pas non plus si c'est un renommage unique ou si il sera répété.

Watael · Le 10/07/2019, à 18:57

renommer en masse par script pour que les fichiers perdent le chemin dans leurs noms

ça ne veut rien dire !
le chemin, c'est le chemin,
le nom, c'est le nom !

on ne peut pas enlever le chemin du nom de fichier, puisque c'est le chemin : il ne fait pas partie du nom.

`comprends pas.

nam1962 · Le 10/07/2019, à 19:14

@Watael : ce peut-être un contresens sur la base de mv : renommer, plutôt que déplacer
Sur la base de plein de chemins, un objectif peut-être de les "groupir" à un seul endroit (mais alors il faut vérifier les homonymes en plus).

Mais tu as total raison, on ne peut qu'attendre des précisions.

DonutMan75 · Le 11/07/2019, à 07:37

Bonjour,
s'il s'agit de mettre l'arborescence à plat, peut-être qu'un find ferait l'affaire ?

find . -name "*txt" -exec mv {} ./ \;

Mais là, je suppose :

que c'est bien ce que souhaite faire Jean-Paul 3,
qu'on se place bien dans le répertoire racine où tous les fichiers txt sont crées,
qu'il n'y a bien QUE ces fichiers txt et pas d'autres truc,
et enfin, bien entendu et comme l'a remarqué nam1962, qu'il n'y a aucun doublon dans les noms de fichiers...

Bonne journée à tous !

Donut

Jean-paul 3 · Le 11/07/2019, à 08:45

Houla, bonjour et merci pour le nombre de réponses.

Je m’aperçois que je me suis peut-être mal exprimé.
Les fichiers nommés tel que vu plus haut ne sont plus dans le système, ils sont copiés puis exportés dans un volume tierce par contre effectivement ces fichiers gardent dans leur nom l'intégralité du chemin de l’arborescence du système et c'est cela que j'aimerai nettoyer en masse pour ne garder que le nom du fichier.
Quelque chose de propre quoi !
;=)

FrancisFDZ · Le 11/07/2019, à 08:52

Bonjour,
Je ferais même remarquer que rien n’empêche la présence de deux fichiers différents mais homonymes dans deux répertoires différents, ce qui ne simplifie pas le tri !

Watael · Le 11/07/2019, à 10:12

rien n’empêche la présence de deux fichiers différents mais homonymes dans deux répertoires différents

+1

Les fichiers nommés tel que vu plus haut ne sont plus dans le système, ils sont copiés puis exportés dans un volume tierce par contre effectivement ces fichiers gardent dans leur nom l'intégralité du chemin de l’arborescence du système

ça n'a pas plus de sens.
cf. #8

EDIT:
il faut nous expliquer en détail ce qui t'a conduit à cette situation (qu'il faut également expliciter), et ce que tu veux obtenir.

Dernière modification par Watael (Le 11/07/2019, à 10:44)

FrancisFDZ · Le 11/07/2019, à 11:48

Watael a écrit :

EDIT:
il faut nous expliquer en détail ce qui t'a conduit à cette situation (qu'il faut également expliciter), et ce que tu veux obtenir.

+1
Normalement, le caractère "/" est interdit (par le système) dans la dénomination d'un fichier

nam1962 · Le 11/07/2019, à 13:15

Je continue à penser à une maladresse d'expression.

Grosso ce que je pige :
Une foultitude de .txt fut déversée sur un disque en bordel avec leur chemin respectifs
Il faut ranger les fichiers dans un chemin unique via une commande ou un script (une commande doit suffir, sauf si c'est un tâche répétitive)

La clef du script sera la commande mv.

Est-ce çà ?

Dernière modification par nam1962 (Le 11/07/2019, à 13:15)

Watael · Le 11/07/2019, à 15:13

ah, oui, moi aussi, c'est pour ça que je demande de donner des détails, ça devrait "obliger" à reformuler...

Dernière modification par Watael (Le 11/07/2019, à 16:06)

LeoMajor · Le 11/07/2019, à 16:05

bonjour,

je comprends une migration de ibm (jfs?) à nunux (ext4-3?)

JFS ... Allowed characters in filenames Any Unicode except NUL (#wikipedia)

sudo apt install fstransform jfsutils  libguestfs-jfs

commandes

./fstransform_0.9.3-1_amd64.deb
./usr/sbin/
./usr/sbin/fsmove
./usr/sbin/fsremap
./usr/sbin/fstransform

./jfsutils_1.1.15-2.1_amd64.deb
./sbin/
./sbin/jfs_fscklog
./sbin/jfs_fsck
./sbin/jfs_tune
./sbin/mkfs.jfs
./sbin/jfs_logdump
./sbin/jfs_debugfs
./sbin/mkfs.jfs
./sbin/jfs_fsck

./libguestfs-jfs_1%3a1.32.2-4ubuntu2.2_amd64.deb

:~/tmps$ zcat ./usr/share/doc/fstransform/README.gz

###############################################################################
###############################################################################
###############################################################################
#########                                                             #########
#########             THIS DOCUMENT EXPLAINS HOW TO USE               #########
#########               RISKY PROGRAMS AND PROCEDURES                 #########
#########        THAT MAY COMPLETELY AND IRREVERSIBLY DELETE          #########
#########                ALL THE DATA ON YOUR DISKS                   #########
#########                                                             #########
#########         THE AUTHOR DECLINES ALL RESPONSIBILITIES            #########
#########               FOR ANY DAMAGE THAT MAY DERIVE                #########
#########           FROM USING THE PROGRAMS AND PROCEDURES            #########
#########               DESCRIBED IN THIS DOCUMENT                    #########
#########                                                             #########
###############################################################################
###############################################################################
###############################################################################

This document explains how use the programs 'fstransform', 'fsmove'
and 'fsremap' to transform the contents of a Linux device
- usually a disk partition - from a filesystem type to another
while preserving its contents.

For example, a disk partition can be transformed from 'jfs' to 'ext4',
or from 'ext2' to 'xfs', or many other combinations. 

Currently, the programs mentioned above have been tested on Linux
with the following filesystems, both as source and as target:
ext2, ext3, ext4, reiserfs, jfs, xfs.

Do NOT use these programs with other filesystems
unless you are willing to LOSE your data.

In particular, they do NOT (yet) support ntfs, msdos and vfat file systems.

Common sense and experience tell that you should ALWAYS have a backup
of your valuable data: while the programs do NOT need to backup your data
to operate, YOU need a backup in case something goes wrong.

The programs have been tested carefully, yet there is ALWAYS a possibility
that they will irreversibly delete ALL the data on the device you run them on,
even if you use a tested combination of filesystems.

All this foreword means only one thing:

      IF YOU LOSE YOUR DATA, IT IS YOUR PROBLEM.

The author declines ALL responsibilities for ANY damage that may derive
from using the programs and procedures described in this document.

###############################################################################
###############################################################################
###############################################################################

Enough legalese... now let's get to the interesting part.

The program 'fstransform' does the following:

it takes a device with a filesystem on it (even if almost full)
and transforms the device to a different filesystem type,
in-place (i.e. without backup) and non-destructively
(i.e. it preserves all your data).

It works even if the filesystem is almost full
- several empyrical tests have succeeded even with a 95% full filesystem -
and even if it contains very large files, for example if some files
are larger than half the device or larger than the available space.

There are four requirements for fstransform to have a chance to succeed:

1) the device must have a little free space, typically at least 5%

   WARNING: transforming an almost full device to 'xfs' file-system
   can be tricky:
   * you need either slightly more free space, typically at least 10%,
   * or you must be VERY quick at suspending fstransform 
     when either the source or the target (or both) file-system is almost full
     and run 'xfs_fsr' on the source or target device (or both)
     before resuming fstransform.
     A future fstransform version may automate this operation.

2) the filesystem on the device must support SPARSE FILES, i.e. files with holes
   (see for example http://en.wikipedia.org/wiki/Sparse_file for an explanation of what they are)
   and at least one of the two system calls "ioctl(FS_IOC_FIEMAP)" or "ioctl(FIBMAP)"
   (see the file Documentation/filesystems/fiemap.txt in any recent Linux kernel
   for an explanation, or search for the same file on Internet)

3) the initial and final filesystems must be supported by the Linux kernel
   (i.e. it must be able to mount them)
   and by the tools 'mkfs' and 'fsck'
   (i.e. it must be possible to create them and check them for errors)

4) the following programs must be available:
   the two custom-made programs 'fsmove' and 'fsremap' (distributed with the script)
   and several common Linux tools:
      which, expr, id, blockdev, losetup, mount, umount,
      mkdir, rmdir, rm, mkfifo, dd, sync, fsck, mkfs 


FOREWORD:

If the original device is almost full, the program 'fsremap'
will create a relatively small backup file ("secondary storage")
inside the directory /var/tmp/fstransform.
This secondary storage file will be at most as large as half your free RAM.

You can pass the option '-s <size>[k|M|G|T|P|E|Y|Z]' to the tool 'fsremap'
in order manually set the secondary storage size,
but please understand that using a too small secondary storage
can slow down the procedure.

To pass the same option to 'fstransform', you must execute something like
  fstransform --opts-fsremap='-s <size>' <other-options-and-arguments> 


PROCEDURE:

0) compile fsmove and fsremap.
   Running "./configure" then "make" should suffice on any recent Linux machine,
   as long as g++ is installed.
   
   You will get two executables, fsmove and fsremap.
   They will be located at
     fstransform-{version}-src/fsmove/Release/fsmove
   and
     fstransform-{version}-src/fsremap/Release/fsmap
   
   You are suggested to either run "make install" or to copy them to a simpler path.
   Below, they will be referred as {fsmove} and {fsremap}


1) OPTIONAL - CAN BE SKIPPED
   mount read-write the device you want to remap to a new file-system type

   mount {device} {device-mount-point} [your-options]

   if the device is already mounted, check that it is mounted read-write
   and that no process is using it.

2) decide the target file-system type.

   For some combinations of the initial and final filesystems
   it is not necessary to use 'fstransform',
   as the same result can be obtained with much simpler - and SAFER - tools.

   For example, an 'ext2' or 'ext3' filesystem can be transformed into 'ext3'
   or 'ext4' using the program 'tune2fs'.
   
   Explaining how to use 'tune2fs' is beyond the scope of this document,
   just read its man-page or search on the Internet for one of
   "convert Linux File System ext2 to ext3" 
   "convert Linux File System ext2 to ext3" 
   "convert Linux File System ext3 to ext4" 
   
   But for most combinations, the only way is either to do a full backup + format +
   restore the data, or use 'fstransform'

3) execute the program

   fstransform {device} {target-file-system-type}

4) follow the instructions - the program will tell you what it is doing,
   and will also call 'fsmove' and 'fsremap' which show progress percentage
   and estimated time left.
   
   Note that 'fsmove' and 'fsremap' need approximately the same time to run,
   so if 'fsmove' tells you that it will need 2 hours, 'fsmove' will
   likely need a similar amount of time, for a total of 4 hours.

   In case there are errors, you can even try to fix them instead of
   aborting the execution (if you know what you are doing).
   
5) be PATIENT. Transforming a large device takes a LONG time...
   On a fairly fast disk, it takes about 1 minute per 1 gigabyte.
   It means transforming 250GB of takes about 4 hours.
   Solid state disks (SSD) can be much faster.
   
6) if something goes really wrong, check in /var/tmp/fstransform
   for the log files
   fstransform.log.<NNN> and fsremap.job.<MMM>/fsremap.log
   they are ABSOLUTELY necessary if you want someone to analyze the problem
   - but unless you are very lucky you can forget about recovering your data...

7) if for some reason the execution is interrupted while 'fsremap' is running,
   for example due to a power failure, it is possible to resume it
   by running 'fsremap --resume-job=<MMM> {device}'.
   Also, 'fsremap' will show at its startup the exact command line
   needed to resume its execution.

Good luck!

Massimiliano Ghilardi
<paperinik@users.sf.net>

-----------

-copie partition IBM puis montage
-opération de conversion fstransform fsmove fsremap
-opération de renommage en dernier

Watael · Le 11/07/2019, à 16:10

mais.... comment on distingue le chemin des noms ? 8O

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 10/07/2019, à 17:02

Renommage en masse fichier

#2 Le 10/07/2019, à 17:09

Re : Renommage en masse fichier

#3 Le 10/07/2019, à 17:13

Re : Renommage en masse fichier

#4 Le 10/07/2019, à 18:29

Re : Renommage en masse fichier

#5 Le 10/07/2019, à 18:36

Re : Renommage en masse fichier

#6 Le 10/07/2019, à 18:42

Re : Renommage en masse fichier

#7 Le 10/07/2019, à 18:50

Re : Renommage en masse fichier

#8 Le 10/07/2019, à 18:57

Re : Renommage en masse fichier

#9 Le 10/07/2019, à 19:14

Re : Renommage en masse fichier

#10 Le 11/07/2019, à 07:37

Re : Renommage en masse fichier

#11 Le 11/07/2019, à 08:45

Re : Renommage en masse fichier

#12 Le 11/07/2019, à 08:52

Re : Renommage en masse fichier

#13 Le 11/07/2019, à 10:12

Re : Renommage en masse fichier

#14 Le 11/07/2019, à 11:48

Re : Renommage en masse fichier

#15 Le 11/07/2019, à 13:15

Re : Renommage en masse fichier

#16 Le 11/07/2019, à 15:13

Re : Renommage en masse fichier

#17 Le 11/07/2019, à 16:05

Re : Renommage en masse fichier

#18 Le 11/07/2019, à 16:10

Re : Renommage en masse fichier

Pied de page des forums