Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 29/06/2023, à 17:12

Halesque

Récupération de fichiers : le format .odt non-pris en charge ?

Bonjour,
suite à une mise à jour (?), tous mes fichiers ont disparus (même l'image de fond du bureau).  Les dossier sont toujours là mais vides.
J'ai tenté de récupérer tout ça avec foremost et testdisk/photorec et j'en ai retrouvé une partie (+ tout un tas de trucs inutiles) mais par contre ces 2 méthodes n'ont pas retrouvé les fichiers .odt (un format visiblement à part).
J'ai plusieurs documents sur lesquels j'aimerais vraiment remettre la main.
Si quelqu'un a une idée !
Merci !

Hors ligne

#2 Le 29/06/2023, à 19:34

Vobul

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Dans "FileOpts" t'as odt ?

J'ai trouvé pas mal de threads similaires à ton problème (recherche: "testdisk odt"), donc ce n'est pas que toi.

En dernier recours : https://www.cgsecurity.org/wiki/Add_you … o_PhotoRec

Mais normalement les .odt sont reconnus.


Vobul
Utilisez le retour utilisable de commandes !!!
J'aime la langue française, mais je parle franglais, deal with it.
RTFM

Hors ligne

#3 Le 29/06/2023, à 20:03

Halesque

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Merci ! Je vais essayer ça (et regarder les autres messages aussi, j'avais pas vu... oops...)

Hors ligne

#4 Le 29/06/2023, à 20:42

Halesque

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Sinon, non j'ai pas odt dans "FileOpts"

Je vais tenter de le rajouter grâce au lien que tu m'as envoyé, mais je suis un gros noob, donc c'est pas gagné...

Hors ligne

#5 Le 29/06/2023, à 20:50

Vobul

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Bah au pire t'as apris une leçon cruciale : les sauvegardes c'est important ! wink


Vobul
Utilisez le retour utilisable de commandes !!!
J'aime la langue française, mais je parle franglais, deal with it.
RTFM

Hors ligne

#6 Le 29/06/2023, à 21:00

Halesque

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Eheh ! Oui, ça va : la plupart des trucs sont au chaud !
Mais les fichiers récents sont passés je ne sais pas où et il y en a quelques uns pour lesquels ça m'embête vraiment...
D'autant plus surpris que je ne pensais vraiment pas qu'un format comme odt poserait souci...

Hors ligne

#7 Le 29/06/2023, à 21:55

Coeur Noir

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Hello,

suite à une mise à jour (?), tous mes fichiers ont disparus (même l'image de fond du bureau).

…c'est quand même assez rare que de des tas de fichiers disparaissent subitement.

Il faudrait s'assurer qu'ils n'ont pas simplement été déplacés ?
Ou - s'ils étaient stockés sur des disques / partitions distincts - que leurs montages sont toujours là ?
Ou encore, qu'ils seraient devenus inaccessibles / invisibles à ton $USER suite à des changements de droits et permissions sur eux ou l'emplacement les contenant ?
Ou que leurs contenants faisaient l'objet de liens symboliques qui, eux, seraient cassés ou auraient été effacés ?
→ sous-entendu : à première vue, j'ai du mal à croire que des choses disparaissent définitivement ; je songe plutôt à un accès qui ne se fait plus vers quelque chose qui existe toujours.

Est-ce que

sudo find /home/* -type f -iname *.odt -exec ls -l {} \;

ou

sudo find /media/* -type f -iname *.odt -exec ls -l {} \;

te montrent certains des fichiers que tu pensais avoir perdu ?

Histoire d'avoir une idée de ton contexte en terme de disques et partitions :

lsblk -fe7,11 -o +size,model | cat

et

cat /etc/fstab

Y'a-t-il eu ces derniers temps des opérations administratives « lourdes » sur ton système, genre modifier des partitions, ajouter des disques, réinstallation d'un OS ?
Ou des « moins lourdes » mais qui auraient nécessité de passer des commandes avec sudo ? ( un usage inopportun de sudo peut changer des droits et permissions sur des emplacements ou des fichiers… )

Dernière modification par Coeur Noir (Le 29/06/2023, à 22:05)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#8 Le 29/06/2023, à 22:56

Halesque

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Oui, je voulais un logiciel de capture vidéo et j'en ai installé/désinstallé plusieurs avant d'en trouver un que j'arrivais à faire fonctionner.
Soit via un terminal soit via "Logiciel" (le gestionnaire d'appli).

- Dans le terminal, j'ai peut être effectivement fait de la m*** avec sudo
- Dans "Logiciel", j'avais plusieurs mises à jour qui trainaient depuis longtemps et qu'il n'arrivait pas à faire qui se sont faites ce jour-là.

C'est en redémarrant l'ordi après les mises à jour que tout avait "disparu". Comme tu le suggères, je pense que ça doit être quelque part. D'ailleurs, avec foremost et testdisk/photorec, j'ai retrouvé entre autre plusieurs pdf qui étaient rangés au même endroits que les docs odt que je cherche. Le problème, c'est que ça m'a ressorti des dizaines de milliers de fichiers inutiles (notamment des fichiers temporaires de navigation web), et j'ai peur que ça se soit empilé sur ce que je cherche et que ça ne devienne de plus en plus difficile de remettre la main dessus...

Je vais tester les lignes de commande que tu m'as fait passer. Merci !

Hors ligne

#9 Le 29/06/2023, à 23:13

Halesque

Re : Récupération de fichiers : le format .odt non-pris en charge ?

sudo find /home/* -type f -iname *.odt -exec ls -l {} \;

et

sudo find /media/* -type f -iname *.odt -exec ls -l {} \;

n'ont rien donné :
- la 1ère m'a juste sorti un document odt qui se trouve à l'heure actuelle là où étaient les autres (que j'ai mis là pour qu'un des logiciels de récupération essaie d'identifier le format)
- la deuxième a juste trouvé des docs qui sont sur un autre disque (le disque dur de mon ancien PC qui est maintenant dans la tour en parallèle de l'autre)

Hors ligne

#10 Le 29/06/2023, à 23:50

Coeur Noir

Re : Récupération de fichiers : le format .odt non-pris en charge ?

des docs qui sont sur un autre disque (le disque dur de mon ancien PC qui est maintenant dans la tour en parallèle de l'autre)

Mmm… donc il faut contextualiser davantage.
Tu as plusieurs disques et partitions.
S'assurer que toutes ces partitions sont bien exploitables depuis ton système ( qu'elles sont bien montées quelque part dans ton système, dans un dossier. )
Ce sont les 2 autres commandes proposées au #7 ( lsblk et cat ).

Je soupçonne : tes données sont dans des partitions qui ne sont plus montées.

Est ce que l'idée d'une « partition /home séparée » ou de « monter des partitions dès le démarrage de ton système » ça évoque quelque chose que tu aurais mis en place ?

Pour montrer les commandes sudo passées par ton terminal, c'est

history | grep sudo

Dernière modification par Coeur Noir (Le 29/06/2023, à 23:57)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#11 Le 30/06/2023, à 16:55

Halesque

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Ok,
la commande

history | grep sudo

n'a fait remonter que les commandes sudo post-bug.
Je n'ai pas le souvenir d'avoir touché aux disques, comme je n'y connais pas grand chose j'essaie de faire attention. Mais ça a pu m'arriver de suivre aveuglément des indications trouvées sur le net sans vraiment comprendre ce que je faisais, donc...

Sinon, les autres commandes ont donné ça :

alex@cogip:~$ lsblk -fe7,11 -o +size,model | cat
NAME   FSTYPE FSVER LABEL         UUID                                 FSAVAIL FSUSE% MOUNTPOINTS                                 SIZE MODEL
sda                                                                                                                             465,8G WDC WD5000AUDX-73H9TY0
├─sda1 vfat   FAT32               ACB7-89AF                              40,2M    13% /boot/efi                                    47M 
├─sda2 ext4   1.0                 6e42a336-c9a0-402c-8f65-a79e8358f60d   15,8G    60% /var/snap/firefox/common/host-hunspell     46,6G 
│                                                                                     /                                                
└─sda3 ext4   1.0                 ccdb7aa9-f919-49a6-bfbf-4f35fde22c48  333,3G    14% /home                                     419,1G 
sdb                                                                                                                             931,5G WDC WD10EADS-65M2B0
├─sdb1 ntfs         SYSTEM        4074DE7D74DE755E                       42,6M    57% /mnt/4074DE7D74DE755E                       100M 
├─sdb2 ntfs         HP            F09ADA949ADA56A6                                                                              918,8G 
└─sdb4 ntfs         FACTORY_IMAGE 8E96F4F496F4DE21                                                                               12,7G 
sdc                                                                                                                             465,8G WDC WD5000AAKS-75YGA0
└─sdc1 ext4   1.0   Data          a40633e2-9022-4282-b6b3-76aefbaf1861  434,1G     0% /mnt/a40633e2-9022-4282-b6b3-76aefbaf1861 465,8G

A priori, les docs qui ont disparus sont/étaient sur sda3

alex@cogip:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=6e42a336-c9a0-402c-8f65-a79e8358f60d /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=ACB7-89AF  /boot/efi       vfat    umask=0077      0       1
# /home was on /dev/sda3 during installation
UUID=ccdb7aa9-f919-49a6-bfbf-4f35fde22c48 /home           ext4    defaults        0       2
/swapfile                                 none            swap    sw              0       0
/dev/disk/by-uuid/a40633e2-9022-4282-b6b3-76aefbaf1861 /mnt/a40633e2-9022-4282-b6b3-76aefbaf1861 auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-uuid/4074DE7D74DE755E /mnt/4074DE7D74DE755E auto nosuid,nodev,nofail,x-gvfs-show 0 0

Si ça peut éclairer ta compréhension de la situation, c'est cool !

Merci !

Hors ligne

#12 Le 30/06/2023, à 20:09

Nuliel

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Bonjour,
Juste pour info, le format odt c'est "juste" une archive zip (comme tous les formats openDocument), avec des fichiers particuliers dedans: content.xml, ... Bref au pire testdisk/photorec devraient réussir à les retrouver sous format zip (il suffirait alors de regarder la présence de fichiers spécifiques dans les zip extraits). Mais je pense la même chose que Coeur Noir, tes données sont probablement dans une autre partition.

Hors ligne

#13 Le 30/06/2023, à 20:51

Halesque

Re : Récupération de fichiers : le format .odt non-pris en charge ?

J'ai effectivement récupéré pas loin de 2000 fichiers zip avec testdisk/photorec mais si j'essaie d'en ouvrir un, ça me dit que c'est impossible car l'emplacement n'est pas monté... ce qui confirmerait qu'ils sont par là quelque part...

Hors ligne

#14 Le 30/06/2023, à 23:40

Coeur Noir

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Si ça peut éclairer ta compréhension de la situation, c'est cool !

La compréhension, peut-être pas, mais voilà ce que j'en déduis, tu confirmeras ou pas ;-)

⋅ Il y a 3 disques dans ta machine ;
⋅ le disque sda contient Ubuntu dans une partition et /home dans une autre ;
⋅ /home contient ± 85 Go de données ;
⋅ le disque sdb a l'air réservé à Windows ;
⋅ le disque sdc est dans un format Linux et contient ± 31 Go de données.

⋅ les partitions 1, 2 et 3 de sda sont montées dès le démarrage aux endroits opportuns ;
⋅ je ne comprends pas l'intérêt de monter la partition 1 de sdb ( vu la taille ce n'est pas l'OS Windows ) ;
⋅ la partition 1 de sdc est également montée ( celle qui contient ± 31 Go de données ) ;
⋅ les partitions de sdb et sdc ont été montées via un utilitaire graphique du genre « disques » ou gnome-disk ( d'où l'emploi de /mnt et des uuid pour nommer les points de montage, ou l'option x-gvfs-show ).

Bref, il y a un peu de données dans :
⋅ /home
⋅ /mnt/a40633e2-9022-4282-b6b3-76aefbaf1861
c'est donc là-dedans qu'il faut regarder s'il y a des choses intéressantes à trouver :

ls -la /home/*
ls -la /mnt/a40633e2-9022-4282-b6b3-76aefbaf1861/*

Dans sdb c'est la partition 2 qui contient peut-être quelque chose d'intéressant ( taille 918 Go mais comme elle n'est pas montée, on ne voit pas ce qu'il y a dedans ).
Est-ce que tu as un temps « partagé » des données entre tes 2 OS c'est à dire, depuis Ubuntu as-tu parfois accédé à des documents enregistrés par exemple sous C:\windows\users\… ?
Si tu veux regarder par là, dans cette partition, tu peux la monter via

udisksctl mount -b /dev/sdb2

ses données deviendront alors accessibles via /media/ton_nom/HP
( ou si tu ne veux pas passer par une commande, passe par ton explorateur de fichiers → autres emplacements → clique sur sdb2 → c'est exactement la même chose que la commande udisksctl )


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#15 Le 01/07/2023, à 11:08

Halesque

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Salut,
et merci !

- En ce qui concerne le disque sdb / sdb2 / hp, c'est le disque dur de mon ancien PC. J'avais la flemme de copier/coller tout ce qu'il y a dessus donc j'ai tout laissé là et j'y accède régulièrement (dans l'explorateur de fichiers, "HP" apparait directement dans "autres emplacements"). Dessus, il y a toutes mes données jusqu'à il y a 2 ans, avant que je ne récupère cette tour montée sous Linux, et je m'en sers aussi pour quelques sauvegardes maintenant, en parallèle d'un DD externe.
En tout cas, tout fonctionne normalement de ce côté-là : tout y est encore à sa place, rien n'a bougé et j'y accède sans problème.

- Pour la partition 1 de sdb "System", effectivement, je pense que ça ne sert à rien... Ça doit être des trucs de mon ancien windows...

-

la partition 1 de sdc est également montée ( celle qui contient ± 31 Go de données )

Ben, à priori oui, mais quand je l'ouvre dans l'explorateur de fichiers (autres emplacements/data), ça me dit que le dossier est vide... De toute façon, je ne pense pas m'en être déjà servi...

- Les trucs que j'ai perdu étaient à priori dans sda3, avec ta commande

ls -la /home/*
ls -la /mnt/a40633e2-9022-4282-b6b3-76aefbaf1861/*

ça ne trouve que ce qu'il y a dessus à l'heure actuelle (à savoir les résultats des recherches que j'ai faites avec foremost et testdisk/photorec) (oui c'était sûrement pas une bonne idée de les mettre au même endroit mais j'ai pas réussi à les faire enregistrer ailleurs...)

alex@cogip:~$ ls -la /home/*
ls -la /mnt/a40633e2-9022-4282-b6b3-76aefbaf1861/*
/home/alex:
total 2759460
drwxr-xr-x 34 alex alex       4096 juin  29 21:42  .
drwxr-xr-x  4 root root       4096 avril 19  2021  ..
-rw-rw-r--  1 alex alex    6994287 juin  27 22:56 '2023-06-27 22-55-15.mkv'
-rw-rw-r--  1 alex alex    8869378 juin  27 23:01 '2023-06-27 23-00-28.mkv'
-rw-rw-r--  1 alex alex 1417435830 juin  27 23:04 '2023-06-27 23-04-02.avi'
-rw-rw-r--  1 alex alex 1391903382 juin  27 23:09 '2023-06-27 23-09-05.avi'
-rw-------  1 alex alex       2036 juin  30 23:14  .bash_history
drwxr-xr-x  2 alex alex       4096 juin  28 00:08  Bureau
drwx------ 20 alex alex       4096 juin  29 22:24  .cache
drwxr-xr-x 22 alex alex       4096 juin  30 23:05  .config
drwxr-xr-x  2 alex alex       4096 juin  28 09:52  Documents
drwx------  2 alex alex       4096 juin  27 21:31  Downloads
-rw-rw-r--  1 alex alex        254 juin  29 21:51  fidentify.log
drwxr-xr-x  2 alex alex       4096 juin  27 21:50  Images
-rw-------  1 alex alex         20 juin  29 13:50  .lesshst
drwx------  3 alex alex       4096 juin  27 21:12  .local
drwxr-xr-x  2 alex alex       4096 juin  27 21:50  Modèles
drwx------  3 alex alex       4096 juin  27 20:57  .mozilla
drwxr-xr-x  2 alex alex       4096 juin  27 21:50  Musique
drwxr-xr-- 21 root root       4096 juin  30 23:06  output
-rw-r--r--  1 root root      40960 juin  29 13:50  photorec.se2
drwx------  3 alex alex       4096 juin  27 21:32  .pki
drwxr-xr-x  2 alex alex       4096 juin  27 21:50  Public
drwxr-xr-x  2 root root      20480 juin  29 14:04  recup_dir.1
drwxr-xr-x  2 root root      20480 juin  29 15:17  recup_dir.10
drwxr-xr-x  2 root root      20480 juin  29 15:18  recup_dir.11
drwxr-xr-x  2 root root      20480 juin  29 15:18  recup_dir.12
drwxr-xr-x  2 root root      20480 juin  29 15:20  recup_dir.13
drwxr-xr-x  2 root root      20480 juin  29 15:47  recup_dir.14
drwxr-xr-x  2 root root      12288 juin  29 16:08  recup_dir.15
drwxr-xr-x  2 root root      20480 juin  29 14:04  recup_dir.2
drwxr-xr-x  2 root root      20480 juin  29 14:04  recup_dir.3
drwxr-xr-x  2 root root       4096 juin  29 14:04  recup_dir.4
drwxr-xr-x  2 root root      20480 juin  29 14:52  recup_dir.5
drwxr-xr-x  2 root root      20480 juin  29 14:52  recup_dir.6
drwxr-xr-x  2 root root      12288 juin  29 14:52  recup_dir.7
drwxr-xr-x  2 root root      20480 juin  29 15:06  recup_dir.8
drwxr-xr-x  2 root root      20480 juin  29 15:16  recup_dir.9
drwx------ 19 alex alex       4096 juin  27 21:17  snap
drwxrwxr-x  5 alex alex       4096 juin  27 21:06  .ssr
-rw-r--r--  1 alex alex          0 juin  27 21:00  .sudo_as_admin_successful
drwxr-xr-x  3 alex alex      12288 juin  29 22:51  Téléchargements
-rw-r--r--  1 root root      29543 juin  29 16:27  testdisk.log
drwxr-xr-x  2 alex alex       4096 juin  27 23:08  Vidéos
ls: impossible d'ouvrir le répertoire '/home/lost+found': Permission non accordée
ls: impossible d'ouvrir le répertoire '/mnt/a40633e2-9022-4282-b6b3-76aefbaf1861/lost+found': Permission non accordée 

J'ai une capacité quasi nulle à appréhender la situation mais je me demande quand même 2 choses :

- Quel est ce "home/lost+found' non accessible ?

- Il trouve des trucs dans 'alex alex', or je pensais que c'était 'alex cogip' (j'avais changé le nom d'user ya plusieurs mois, j'espère ne pas en avoir créé un autre... Mais comme c'était ya quelques mois, ça aurait fichu la pagaille avant non ?)

Merci pour les tuyaux ! wink

Hors ligne

#16 Le 01/07/2023, à 14:38

Coeur Noir

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Appeler un chat un chat… bien nommer les choses ça aide aussi à clarifier « ce qui se passe » pour que ces choses existent.

En ce qui concerne le disque sdb / sdb2 / hp, c'est le disque dur de mon ancien PC

⋅ sdb est le disque ;
⋅ sdb2 est la deuxième partition sur ce disque ;
⋅ HP est l'étiquette de cette partition 2 de sdb ;
⋅ au moment où je l'évoque, dans le message #11 on voit que cette partition sdb2 n'a pas de point de montage.

Tant que sdb2 n'est pas « montée » quelque part dans ton Linux, les données qu'elle contient n'existent pas dans ton Linux, tu ne vois que le périphérique disque, l'objet matériel.
Le « montage » consiste à signifier à ton Linux : « je veux voir les données ( le système de fichiers ) de tel périphérique ( point de vue matériel ) à l'intérieur de tel dossier dans mon système ( point de vue logiciel, logique, organisationnel ) ».

Dans le cas de périphériques de stockage « externes » qu'on branche à chaud au pc, le montage des données se fait automatiquement dans /media/$USER/uuid_ou_label_partition ( en arrière-plan c'est udisks qui gère cela. )
Dans les autres cas il ne se passe rien automatiquement : les périphériques sont certes vus, mais leurs données ne sont montées nulle part.
Soit tu les montes manuellement, temporairement ou définitivement via des commandes ( comme udisksctl mount -b ou sudo mount ) soit via des outils graphique ( explorateur de fichiers, utilitaire disque… )

Les montages « permanents » sont ceux qui sont consignés dans le fichier /etc/fstab : ceux là sont effectués dès le démarrage du système, bien avant le lancement des sessions utilisateurs « humains ».
Tout ce qui n'est pas déjà consigné dans le fichier /etc/fstab sera traité comme un support amovible dont les données ne deviennent exploitables qu'après avoir sollicité volontairement une partition ( en graphique ou en commande, c'est pareil. )

Après ce petit point sur la chronologie des événements qui permettent d'accéder à des données, une hypothèse est que ce que tu cherches était peut-être dans sdb2 ?
Apparemment non…

Dernière modification par Coeur Noir (Le 01/07/2023, à 14:46)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#17 Le 01/07/2023, à 14:56

Coeur Noir

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Quel est ce "home/lost+found' non accessible ?

J'espérais bien qu'ils seraient là.
Ce dossier existe toujours à la racine d'une partition EXT× ; il sert de « point de chute » lorsqu'il y a des accidents dans le système de fichiers ou des incohérences que le système ne sait pas régler.
Tant que tout va bien ces dossiers sont vides.
Il appartient légitimement à l'utilisateur ( et au groupe ) root car c'est le système qui gère directement ce qui concerne les partitions et les systèmes de fichiers qu'elles hébergent.

Regardons s'il y a quelque chose par là :

sudo ls -la /home/lost+found
sudo ls -la /mnt/a40633e2-9022-4282-b6b3-76aefbaf1861/lost+found

S'il y a des éléments stockés par là, il faudra s'intéresser à la réparation des systèmes de fichiers → fsck


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#18 Le 01/07/2023, à 15:00

Halesque

Re : Récupération de fichiers : le format .odt non-pris en charge ?

ça donne ça :

alex@cogip:~$ sudo ls -la /home/lost+found
sudo ls -la /mnt/a40633e2-9022-4282-b6b3-76aefbaf1861/lost+found
[sudo] Mot de passe de alex : 
total 20
drwx------ 2 root root 16384 mai   24  2021 .
drwxr-xr-x 4 root root  4096 avril 19  2021 ..
total 20
drwx------ 2 root root 16384 mai   24  2021 .
drwxrwxrwx 4 alex alex  4096 juin  25  2021 .. 

Hors ligne

#19 Le 01/07/2023, à 15:03

Halesque

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Et en ce qui concerne sbd2, dans le message#11, il n'apparait pas monté effectivement, mais dans l'explorateur de fichiers, en face de HD, j'ai l'icône pour le démonter... comme s'il l'était...

Hors ligne

#20 Le 01/07/2023, à 15:18

Coeur Noir

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Il trouve des trucs dans 'alex alex', or je pensais que c'était 'alex cogip'

Dans la série c'est important de bien nommer les choses ;-)
Ce que tu vois dans un retour de ls -l :

(…)
drwxr-xr-x  2 alex alex       4096 juin  27 21:50  Musique
drwxr-xr-- 21 root root       4096 juin  30 23:06  output
(…)

ce sont les propriétaires de l'élément ( fichier, dossier ).
Ici le dossier Musique appartient à l'utilisateur alex et au groupe alex tandis que le dossier output appartient à l'utilisateur root et au groupe root.
Chaque élément accorde des droits spécifiques à l'utilisateur, au groupe et aux autres ( les autres sont le reste du monde : ceux qui ne sont ni l'utilisateur propriétaire ni membre d'un groupe propriétaire ).
Ces droits sont indiqués au début de la ligne, ici rwxr-xr-- pour output signifient : l'utilisateur a les droits lecture+écriture+exécution, le groupe lecture+exécution, les autres seulement lecture.

En théorie dans un $HOME tout est censé appartenir à son $USER titulaire mais ici, ce qu'on voit appartenir à root:root c'est le fruit de l'utilisation des outils de récupération de données qui agissent en tant que root:root pour avoir le plein accès aux infos des partitions et systèmes de fichiers ( un utilisateur normal n'a pas ces accès. )

L'invite que tu vois quand tu ouvres le terminal

alex@cogip:~$

te donnent les informations suivantes :
alex = l'utilisateur actuel de ce terminal ;
cogip = le nom de la machine où alex se trouve en ce moment ;
~ = /home/$USER = $HOME = l'emplacement où agit ce terminal ( par défaut le répertoire personnel de l'utilisateur en cours ) ;
$ = la « qualité » de cet utilisateur → $ pour normal ( sans privilèges administrateur ) ou # ( avec privilèges administrateur, en mode Super Utilisateur tout puissant ).

Dernière modification par Coeur Noir (Le 01/07/2023, à 15:19)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#21 Le 01/07/2023, à 18:10

iznobe

Re : Récupération de fichiers : le format .odt non-pris en charge ?

Bonjour , il se peut aussi que les données aient été deplacées sur un systeme de fichiers non montés par accident . faudrait verifier dans chaque partition , meme celle qui a priori ne servent pas usuellement .

Autre point :

ça ne trouve que ce qu'il y a dessus à l'heure actuelle (à savoir les résultats des recherches que j'ai faites avec foremost et testdisk/photorec) (oui c'était sûrement pas une bonne idée de les mettre au même endroit mais j'ai pas réussi à les faire enregistrer ailleurs...)

en fait , il es indiqué dans les docs de tous ces logiciels d ' ecrire les resultats sur une autre partition sous peine de perdre les fichiers a récupérés ... c ' est donc vraiment une mauvaise idée , surtout que a priori , tu as plein d' espace inutilisé sur d' autres disques / partitions .

Autre chose , il faut que tu t ' attelles a mettre de l ' ordre dans tes partitions , et supprimer celle qui ne servent pas . car là , ca complique grandement les choses .


retour COMPLET et utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .

Hors ligne