search for: fls0

...en used. On FAT, Ext2 and NTFS it can recover part or the whole file pretty easily as long as it's sectors have not been overwritten by others. For Ext3 and Ext4 it's a bit more difficult, usually data carving is more effective in these cases. I haven't tested on other filesystems. The fls0 API works similar to find but it returns more information such as the files/directories metadata addresses (inodes) and whether the files are allocated (in use) or not (deleted). Later on I will add more fine grained APIs such as fls0-d for showing only deleted files and fls0-m which reports the cr...

...example of which type of features TSK can enable. A few comments in general terms: The current splitting of the commits doesn't make much sense to me. I think it would be better as: - commit to add TSK to the appliance - commit to add the icat API - tests for icat - commit to add the fls0 API - tests for fls0 although it would be fine to combine the tests with the new API, or even have all the tests as a single separate commit (as now). This benefits you because it will allow patches to go upstream earlier. For example, a commit to add TSK to the appliance is a simple and obvio...

...few comments in general terms: > > The current splitting of the commits doesn't make much sense to me. > I think it would be better as: > > - commit to add TSK to the appliance > > - commit to add the icat API > > - tests for icat > > - commit to add the fls0 API > > - tests for fls0 > > although it would be fine to combine the tests with the new API, or > even have all the tests as a single separate commit (as now). > > This benefits you because it will allow patches to go upstream > earlier. For example, a commit to add TSK...

...ts commands which > could have a large output is via first dumping it onto a local file > and then iterating over it. > This command would list the entire content of a disk including the > deleted files therefore we need to expect a large output. Your understanding is correct. But the fls0 API still isn't safe because (I assume) it cannot handle filenames containing '\n'. There's another API which handles arbitrary length RStructList returns, which is: guestfs_lxattrlist / guestfs_internal_lxattrlist (see src/file.c:guestfs_impl_lxattrlist and daemon/xattr.c). >...

...quot;\ > +Download a file given its inode from the disk partition (eg. F</dev/sda1>) > +and save it as F<filename> on the local machine. > + > +This allows to download deleted or inaccessible files." }; This one looks OK. > + { defaults with > + name = "fls0"; added = (1, 33, 14); > + style = RErr, [Mountable "device"; FileOut "filename"], []; > + proc_nr = Some 465; > + optional = Some "icat"; > + progress = true; cancellable = true; > + shortdesc = "list the content of the disk&quo...

...("inode must be >= 0"); + return -1; + } + + /* Construct the command. */ + if (asprintf (&cmd, "icat -r %s %" PRIi64, mountable->device, inode) == -1) { + reply_with_perror ("asprintf"); + return -1; + } + + return file_out (cmd); +} + +int +do_fls0 (const mountable_t *mountable) +{ + CLEANUP_FREE char *cmd = NULL; + + /* Construct the command. */ + if (asprintf (&cmd, "fls -pr %s", mountable->device) == -1) { + reply_with_perror ("asprintf"); + return -1; + } + + return file_out (cmd); +} + +static int +f...