Re: Partition information as text file?
On Sat, Feb 02, 2019 at 09:26:31AM -0600, David Wright wrote: > On Sat 02 Feb 2019 at 10:58:09 (+0100), to...@tuxteam.de wrote: > > On Fri, Feb 01, 2019 at 07:05:53PM -0600, David Wright wrote: > > > On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote: > > > > On 02/01/2019 10:15 AM, David Wright wrote: > > > > > [snip] > > > > > > > > > > Interesting. I thought Tcl/Tk was for writing GUIs. ... > > > > > > > > *CAVEAT* LECTOR > > > > It is more like Tk being a GUI interface for Tcl. > > > > > > Sure, and for several other languages, but I assume you wouldn't want > > > a GUI interface for your text-producing script even if you write it > > > in Tcl. > > > > Tcl still makes for a reasonable scripting language. It's just a bit > > different of most "modern" languages (except perhaps shell), so for > > Perlies and Pythoners and PHPers it takes some "getting used" to. > > > > But it is pretty powerful. > > Yes, I remember Tkinter's thinness overlying it: it would occasionally > be necessary to tickle the Tcl to get precisely what you wanted. > > But as for being different, I've found nothing to approach Spitbol > (a superior implementation of Snobol, which I ran on IBM 370s in the > '70s and '80s and then on Vaxen into the mid-'90s). Fortunately > when it fell by the wayside, I found Perl, with its associative > arrays, and even an implementation of Perl on DOS, which kept me > going until I started using Python on linux in late '95. Yes, Snobol and its family was pretty interesting. FWIW, Tcl has gained associative arrays. Cheers -- tomás signature.asc Description: Digital signature
Re: Partition information as text file?
On Sat 02 Feb 2019 at 10:58:09 (+0100), to...@tuxteam.de wrote: > On Fri, Feb 01, 2019 at 07:05:53PM -0600, David Wright wrote: > > On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote: > > > On 02/01/2019 10:15 AM, David Wright wrote: > > > > [snip] > > > > > > > > Interesting. I thought Tcl/Tk was for writing GUIs. ... > > > > > > *CAVEAT* LECTOR > > > It is more like Tk being a GUI interface for Tcl. > > > > Sure, and for several other languages, but I assume you wouldn't want > > a GUI interface for your text-producing script even if you write it > > in Tcl. > > Tcl still makes for a reasonable scripting language. It's just a bit > different of most "modern" languages (except perhaps shell), so for > Perlies and Pythoners and PHPers it takes some "getting used" to. > > But it is pretty powerful. Yes, I remember Tkinter's thinness overlying it: it would occasionally be necessary to tickle the Tcl to get precisely what you wanted. But as for being different, I've found nothing to approach Spitbol (a superior implementation of Snobol, which I ran on IBM 370s in the '70s and '80s and then on Vaxen into the mid-'90s). Fortunately when it fell by the wayside, I found Perl, with its associative arrays, and even an implementation of Perl on DOS, which kept me going until I started using Python on linux in late '95. Cheers, David.
Re: Partition information as text file?
On Fri, Feb 01, 2019 at 07:05:53PM -0600, David Wright wrote: > On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote: > > On 02/01/2019 10:15 AM, David Wright wrote: > > > [snip] > > > > > > Interesting. I thought Tcl/Tk was for writing GUIs. ... > > > > *CAVEAT* LECTOR > > It is more like Tk being a GUI interface for Tcl. > > Sure, and for several other languages, but I assume you wouldn't want > a GUI interface for your text-producing script even if you write it > in Tcl. Tcl still makes for a reasonable scripting language. It's just a bit different of most "modern" languages (except perhaps shell), so for Perlies and Pythoners and PHPers it takes some "getting used" to. But it is pretty powerful. Cheers -- t signature.asc Description: Digital signature
Re: Partition information as text file?
On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote: > On 02/01/2019 10:15 AM, David Wright wrote: > > [snip] > > > > Interesting. I thought Tcl/Tk was for writing GUIs. ... > > *CAVEAT* LECTOR > It is more like Tk being a GUI interface for Tcl. Sure, and for several other languages, but I assume you wouldn't want a GUI interface for your text-producing script even if you write it in Tcl. Cheers, David.
Re: Partition information as text file?
On Fri 01 Feb 2019 at 13:10:19 (-0500), Greg Wooledge wrote: > On Fri, Feb 01, 2019 at 06:06:18PM +, Joe wrote: > > On Fri, 1 Feb 2019 07:59:42 -0600 Richard Owlett > > wrote: > > > > > ... a major deficiency of the man page format -- > > > [/begin_rant almost total lack of examples /end_rant ;] > > > > That's what's expected of man pages. If you want examples, poke around > > the Net for tutorials, and be prepared to find a wide range of quality. > > I disagree. Perhaps you've come to expect a lack of examples from the > man pages published by various GNU projects. GNU developers prefer their > own texinfo format instead, so they often write only stub man pages. > > A well-written man page includes an EXAMPLES section, unless the command > being documented is so trivial that none is required (e.g. true(1)). > > The lack of examples is not a "deficiency of the format". It is a > deficiency of that particular page, written by that particular author. Well, I've just given my opinion elsewhere. But it would be an interesting challenge to write an example of a man page EXAMPLE for that particular page, beyond the example that is given there. Cheers, David.
Re: Partition information as text file?
On Fri, Feb 01, 2019 at 07:30:31PM +0100, Pascal Hambourg wrote: > Le 01/02/2019 à 16:23, to...@tuxteam.de a écrit : > > > > tomas@trotzki:~$ file /dev/mapper/trotzki-home > > /dev/mapper/trotzki-home: symbolic link to ../dm-4 > > > >Ah. > > > > tomas@trotzki:~$ file /dev/dm-4 > > /dev/dm-4: block special (254/4) > > > >Not yet what we wanted. But: > > > > tomas@trotzki:~$ sudo file -s /dev/dm-4 > > In one single command : > > # file -Lsk /dev/mapper/whatever Yep, thanks. I just wanted to sketch a path to the idea. > >Sudo is needed > > No it's not. Read permission on the raw device is needed, by > whatever way including sudo but not only (su, root session...). This is of course more correct than my handwaving description :-) > signature.asc Description: Digital signature
Re: Partition information as text file?
Le 01/02/2019 à 16:23, to...@tuxteam.de a écrit : tomas@trotzki:~$ file /dev/mapper/trotzki-home /dev/mapper/trotzki-home: symbolic link to ../dm-4 Ah. tomas@trotzki:~$ file /dev/dm-4 /dev/dm-4: block special (254/4) Not yet what we wanted. But: tomas@trotzki:~$ sudo file -s /dev/dm-4 In one single command : # file -Lsk /dev/mapper/whatever Sudo is needed No it's not. Read permission on the raw device is needed, by whatever way including sudo but not only (su, root session...).
Re: Partition information as text file?
Greg Wooledge wrote: > On Fri, Feb 01, 2019 at 06:06:18PM +, Joe wrote: > > On Fri, 1 Feb 2019 07:59:42 -0600 > > Richard Owlett wrote: > > > > > ... a major deficiency of the man page format -- > > > [/begin_rant almost total lack of examples /end_rant ;] > > > > That's what's expected of man pages. If you want examples, poke around > > the Net for tutorials, and be prepared to find a wide range of quality. > > I disagree. Perhaps you've come to expect a lack of examples from the > man pages published by various GNU projects. GNU developers prefer their > own texinfo format instead, so they often write only stub man pages. > > A well-written man page includes an EXAMPLES section, unless the command > being documented is so trivial that none is required (e.g. true(1)). ... or the command is so complex that it refers you to other man pages: procmailex perlfaq and perlfaq1-9 -dsr-
Re: Partition information as text file?
On Fri, 1 Feb 2019 07:59:42 -0600 Richard Owlett wrote: > ... a major deficiency of the man page format -- > [/begin_rant almost total lack of examples /end_rant ;] > That's what's expected of man pages. If you want examples, poke around the Net for tutorials, and be prepared to find a wide range of quality. A good place is often (though certainly not always) the documents on the website associated with the application. -- Joe
Re: Partition information as text file?
On Fri, Feb 01, 2019 at 06:06:18PM +, Joe wrote: > On Fri, 1 Feb 2019 07:59:42 -0600 > Richard Owlett wrote: > > > ... a major deficiency of the man page format -- > > [/begin_rant almost total lack of examples /end_rant ;] > > That's what's expected of man pages. If you want examples, poke around > the Net for tutorials, and be prepared to find a wide range of quality. I disagree. Perhaps you've come to expect a lack of examples from the man pages published by various GNU projects. GNU developers prefer their own texinfo format instead, so they often write only stub man pages. A well-written man page includes an EXAMPLES section, unless the command being documented is so trivial that none is required (e.g. true(1)). The lack of examples is not a "deficiency of the format". It is a deficiency of that particular page, written by that particular author.
Re: Partition information as text file?
On 02/01/2019 10:15 AM, David Wright wrote: [snip] Interesting. I thought Tcl/Tk was for writing GUIs. ... *CAVEAT* LECTOR It is more like Tk being a GUI interface for Tcl.
Re: Partition information as text file?
On Fri 01 Feb 2019 at 11:14:11 (-0500), Felix Miata wrote: > Richard Owlett composed on 2019-02-01 07:59 (UTC-0600): > > Thomas Schmitt wrote: > > >> It's what Gparted does and what Richard mentioned as example of the desired > >> information. > > > I'd make that statement stronger. > > My starting point was Gparted displays *ALL* the desired information for > > *ALL* members of the set [ /dev/sd* ] whether mounted or not. > > > That PROVED that what I wanted was possible. > > > It's "suitability to purpose" was degraded on *2* counts: > > 1. it does not output the data as a text file. > > 2. it displays information for only 1 device at a time. > > >> Given that the source code of Gparted is published, we do not > >> have to speculate how it does this, but rather can riddle over its C++ > >> code. > > > Having known working source code for a program that almost meets my > > needs/desires remedies a major deficiency of the man page format -- > > [/begin_rant almost total lack of examples /end_rant ;] > > Maybe the following would do better > > script > parted # instead of gparted > some parted commands > parted exit > script exit > nano typescript > > All assuming you tried dfsee and didn't manage to find options to produce > exactly your > desires in its logs even with some editing. Um, I think that was last Saturday's solution, complete with EXAMPLE (all caps in homage to OP), minutes before your DFSee. Strange, there were no follow-ups then. Let's see if that changes. There's this mighty tree hanging off your DFSee comment. Cheers, David.
Re: Partition information as text file?
On Fri 01 Feb 2019 at 09:00:06 (-0600), Richard Owlett wrote:
> On 02/01/2019 08:22 AM, Thomas Schmitt wrote:
> > Richard Owlett wrote:
> > > [Gparted] PROVED that what I wanted was possible.
> >
> > Regrettably it does not retrieve the information by some universal info
> > program or library, but rather has particular info sources for each of
> > the supported filesystems. (There are more filesystems around than i can
> > see in the Gparted source.)
> >
> > > It's "suitability to purpose" was degraded on *2* counts:
> > > 1. it does not output the data as a text file.
> >
> > So you need one or more scripts ... Then the script[s] would put out
> > the retrieved numbers in the text format which you desire.
>
> The need for *ME* to write a script was a BASIC assumption to my
> asking about commands relevant to my task.
> >
> > > man page format [...] almost total lack of examples [...]
> >
> > If you refer to Gparted's man page, ...
>
> I was referring to Linux man pages in general. I've ~10 man pages of
> commands mentioned in this thread -- none with useful examples. For a
> specific command I routinely do a web search with the keywords
> "examples" &/or "tutorial".
>
> Though I don't refer to myself as a programmer I've written "scripts"
> [using term loosely]:
> in the early 60's using CORC/CUPL {Cornell's predecessor to BASIC}
> in the mid 70's using DEC's TECO {not just an editor ;}
> later dBASEII and Paradox
> am now exploring Tcl/Tk
Interesting. I thought Tcl/Tk was for writing GUIs. I toyed with it
briefly in the late 90s before I started using Tkinter (ie Python).
Cheers,
David.
Re: Partition information as text file?
Richard Owlett composed on 2019-02-01 07:59 (UTC-0600): > Thomas Schmitt wrote: >> It's what Gparted does and what Richard mentioned as example of the desired >> information. > I'd make that statement stronger. > My starting point was Gparted displays *ALL* the desired information for > *ALL* members of the set [ /dev/sd* ] whether mounted or not. > That PROVED that what I wanted was possible. > It's "suitability to purpose" was degraded on *2* counts: > 1. it does not output the data as a text file. > 2. it displays information for only 1 device at a time. >> Given that the source code of Gparted is published, we do not >> have to speculate how it does this, but rather can riddle over its C++ code. > Having known working source code for a program that almost meets my > needs/desires remedies a major deficiency of the man page format -- > [/begin_rant almost total lack of examples /end_rant ;] Maybe the following would do better script parted # instead of gparted some parted commands parted exit script exit nano typescript All assuming you tried dfsee and didn't manage to find options to produce exactly your desires in its logs even with some editing. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Partition information as text file?
On Fri 01 Feb 2019 at 16:23:04 (+0100), to...@tuxteam.de wrote: > Not yet what we wanted. But: > > tomas@trotzki:~$ sudo file -s /dev/dm-4 > /dev/dm-4: Linux rev 1.0 ext4 filesystem data, > UUID=c5d1ae98-df63-4c04-913d-661b82d38075 (needs journal recovery) (extents) > (64bit) (large files) (huge files) > > I guess that's not all info you want, but hey. Sudo is needed, because mere > mortals have no business in reading raw disks, usually; The "needs journal > recovery" sounds alarming, but remember that the thing is mounted, i.e. > active, so that's OK too. I hadn't bothered to say this already, but not replaying the journal could be one reason that wrong information is returned from unmounted filesystems, as Pascal mentioned earlier. That could be another reason to mount them (readonly) and let df complete the dirty work of finding the information you want (as I outlined much earlier in this thread). Cheers, David.
Re: Partition information as text file?
On Fri 01 Feb 2019 at 07:59:42 (-0600), Richard Owlett wrote: > On 01/31/2019 02:03 PM, Thomas Schmitt wrote: > > Hi, > > > > Richard Owlett wrote: > > > > > What bugs me is Gparted [though it does not output text] reports > > > > > used/unused space on each partition/file system. > > > > i wrote: > > > > [...] Gparted runs external programs, which a simple > > > > shell script could do too. > > > > David Wright wrote: > > > So going back to the OP, is this a sensible approach to choose instead > > > of letting mount and df figure things out for themselves? > > > > It's what Gparted does and what Richard mentioned as example of the desired > > information. > > I'd make that statement stronger. > My starting point was Gparted displays *ALL* the desired information > for *ALL* members of the set [ /dev/sd* ] whether mounted or not. I think you mean /dev/sdX*. > That PROVED that what I wanted was possible. We don't doubt that the information is obtainable. My concern was whether you wanted a script to place the required information in a file by COP,¹ or after the indeterminate amount of time it takes to digest and regurgitate all that code. Fortunately the amount of code you need to examine will be reduced by the fact that you personally have a very limited group of partition types in your inventory. > It's "suitability to purpose" was degraded on *2* counts: > 1. it does not output the data as a text file. > 2. it displays information for only 1 device at a time. Yes, the thought of juggling several partition tables simultaneously had probably not occurred to any sane person. > > Given that the source code of Gparted is published, we do not > > have to speculate how it does this, but rather can riddle over its C++ code. > > Having known working source code for a program that almost meets my > needs/desires remedies a major deficiency of the man page format -- > [/begin_rant almost total lack of examples /end_rant ;] Have you tried pressing F1 in the gparted window itself? I was under the impression that man pages were an aide-mémoire for CLI users so that they don't have to commit all the options and arguments to memory. Its flat-file format doesn't really lend itself to copious examples, particularly where they would be trying to describe how to navigate round a widget-filled picture. But this dead horse has been flogged enough times on this list already. Perhaps when your script is finished you could share it here. Many of us are probably running systems with no more than ext & fat filesystems, and could usefully employ it. ¹ Close of Play seems to be missing from wiki's Cop page, even though it appears under End_of_day. Cheers, David.
Re: Partition information as text file?
On Friday, February 01, 2019 09:22:10 AM Thomas Schmitt wrote: > If you refer to Gparted's man page, then the answer is obviously that > nobody expects hard info from the manual of a clicky-colorful GUI program. > (I.e. not "RTFM" but "RTSL" = "Read The Source, Luke.") I hope that's not the case (because I'm an advocate of Linux displacing Windows on the desktop -- I don't expect that target audience to have much success reading the source). Also, on the gparted man page (on Wheezy), I see: More documentation can be found in the application help manual, and online at: http://gparted.org I didn't look at that, but I hope it is a useful resource.
Re: Partition information as text file?
On Fri, Feb 01, 2019 at 09:00:06AM -0600, Richard Owlett wrote: > On 02/01/2019 08:22 AM, Thomas Schmitt wrote: [...] > >So you need one or more scripts ... Then the script[s] would put out > >the retrieved numbers in the text format which you desire. > > The need for *ME* to write a script was a BASIC assumption to my > asking about commands relevant to my task. Perhaps the humble command "file" could be an ally in that. It's not a complete solution, though... Remember: "file" looks (with some exceptions, see below) into the contents of a file and tries to find out what it is, by looking for "magic numbers" (more precisely patterns) stored in a file (/usr/share/misc/magic). Here's a small session from my box (with some elisions marked as [...] tomas@trotzki:~$ mount /dev/sda1 on /boot type ext2 (rw,relatime,block_validity,barrier,user_xattr,acl) /dev/mapper/trotzki-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) /dev/mapper/trotzki-usr on /usr type ext4 (rw,relatime,data=ordered) /dev/mapper/trotzki-home on /home type ext4 (rw,relatime,data=ordered) /dev/mapper/trotzki-var on /var type ext4 (rw,relatime,data=ordered) [...] (Note: my "partitions" are, with exception of /dev/sda1, which is the boot partition, LVM volumes which are cut out from a physical volume which is LUKS encrypted: I don't want someone to get at my (and my customer's) data just because I leave the laptop in the metro). Now: tomas@trotzki:~$ file /dev/mapper/trotzki-home /dev/mapper/trotzki-home: symbolic link to ../dm-4 Ah. tomas@trotzki:~$ file /dev/dm-4 /dev/dm-4: block special (254/4) Not yet what we wanted. But: tomas@trotzki:~$ sudo file -s /dev/dm-4 /dev/dm-4: Linux rev 1.0 ext4 filesystem data, UUID=c5d1ae98-df63-4c04-913d-661b82d38075 (needs journal recovery) (extents) (64bit) (large files) (huge files) I guess that's not all info you want, but hey. Sudo is needed, because mere mortals have no business in reading raw disks, usually; The "needs journal recovery" sounds alarming, but remember that the thing is mounted, i.e. active, so that's OK too. Perhaps this can be a small building block for you. I guess you'd like more info about the file system (size, what not). Those commands (and their outputs!) are most probably file system specific, as Thomas points out. Cheers -- t signature.asc Description: Digital signature
Re: Partition information as text file?
On 02/01/2019 08:22 AM, Thomas Schmitt wrote:
Hi,
Richard Owlett wrote:
[Gparted] PROVED that what I wanted was possible.
Regrettably it does not retrieve the information by some universal info
program or library, but rather has particular info sources for each of
the supported filesystems. (There are more filesystems around than i can
see in the Gparted source.)
It's "suitability to purpose" was degraded on *2* counts:
1. it does not output the data as a text file.
So you need one or more scripts ... Then the script[s] would put out
the retrieved numbers in the text format which you desire.
The need for *ME* to write a script was a BASIC assumption to my asking
about commands relevant to my task.
man page format [...] almost total lack of examples [...]
If you refer to Gparted's man page, ...
I was referring to Linux man pages in general. I've ~10 man pages of
commands mentioned in this thread -- none with useful examples. For a
specific command I routinely do a web search with the keywords
"examples" &/or "tutorial".
Though I don't refer to myself as a programmer I've written "scripts"
[using term loosely]:
in the early 60's using CORC/CUPL {Cornell's predecessor to BASIC}
in the mid 70's using DEC's TECO {not just an editor ;}
later dBASEII and Paradox
am now exploring Tcl/Tk
Re: Partition information as text file?
Hi, Richard Owlett wrote: > [Gparted] PROVED that what I wanted was possible. Regrettably it does not retrieve the information by some universal info program or library, but rather has particular info sources for each of the supported filesystems. (There are more filesystems around than i can see in the Gparted source.) > It's "suitability to purpose" was degraded on *2* counts: > 1. it does not output the data as a text file. So you need one or more scripts which apply the program runs learned from Gparted to your partition device files and which then pick the desired numbers out of the text output from those programs. Then the script[s] would put out the retrieved numbers in the text format which you desire. > man page format [...] almost total lack of examples [...] If you refer to Gparted's man page, then the answer is obviously that nobody expects hard info from the manual of a clicky-colorful GUI program. (I.e. not "RTFM" but "RTSL" = "Read The Source, Luke.") Have a nice day :) Thomas
Re: Partition information as text file?
On 01/31/2019 02:03 PM, Thomas Schmitt wrote: Hi, Richard Owlett wrote: What bugs me is Gparted [though it does not output text] reports used/unused space on each partition/file system. i wrote: [...] Gparted runs external programs, which a simple shell script could do too. David Wright wrote: So going back to the OP, is this a sensible approach to choose instead of letting mount and df figure things out for themselves? It's what Gparted does and what Richard mentioned as example of the desired information. I'd make that statement stronger. My starting point was Gparted displays *ALL* the desired information for *ALL* members of the set [ /dev/sd* ] whether mounted or not. That PROVED that what I wanted was possible. It's "suitability to purpose" was degraded on *2* counts: 1. it does not output the data as a text file. 2. it displays information for only 1 device at a time. Given that the source code of Gparted is published, we do not have to speculate how it does this, but rather can riddle over its C++ code. Having known working source code for a program that almost meets my needs/desires remedies a major deficiency of the man page format -- [/begin_rant almost total lack of examples /end_rant ;] (The ext2 specific code distinguishes between mounted and not mounted partitions. The FAT related code seems not to do.) Have a nice day :) Thomas
Re: Partition information as text file?
Hi, Richard Owlett wrote: > > > What bugs me is Gparted [though it does not output text] reports > > > used/unused space on each partition/file system. i wrote: > > [...] Gparted runs external programs, which a simple > > shell script could do too. David Wright wrote: > So going back to the OP, is this a sensible approach to choose instead > of letting mount and df figure things out for themselves? It's what Gparted does and what Richard mentioned as example of the desired information. Given that the source code of Gparted is published, we do not have to speculate how it does this, but rather can riddle over its C++ code. (The ext2 specific code distinguishes between mounted and not mounted partitions. The FAT related code seems not to do.) Have a nice day :) Thomas
Re: Partition information as text file?
On Thu 31 Jan 2019 at 15:54:57 (+0100), Thomas Schmitt wrote: > Richard Owlett wrote: > > Though I not a C programmer, their organization leads to answers for my > > questions [even a few I hadn't asked]. > > It's C++ in this case. (bleh ...) > > But what i meant is that Gparted runs external programs, which a simple > shell script could do too. > > https://github.com/GNOME/gparted/blob/master/src/ext2.cc#L147 > uses > dumpe2fs -h ...partition.path... > and if the partition is not mounted > resize2fs -P ...partition.path... > > https://github.com/GNOME/gparted/blob/master/src/fat16.cc#L129 > uses > fsck.fat -n -v ...partition.path... > or if that is not present > dosfsck -n -v ...partition.path... > > The Gparted C++ code then looks for particular text snippets in the > output of the programs in order to read the numbers which follow. > > One may suck more hints from the programmers' comments in the lines > which begin by "//". So going back to the OP, is this a sensible approach to choose instead of letting mount and df figure things out for themselves? Cheers, David.
Re: Partition information as text file?
Hi, Richard Owlett wrote: > Though I not a C programmer, their organization leads to answers for my > questions [even a few I hadn't asked]. It's C++ in this case. (bleh ...) But what i meant is that Gparted runs external programs, which a simple shell script could do too. https://github.com/GNOME/gparted/blob/master/src/ext2.cc#L147 uses dumpe2fs -h ...partition.path... and if the partition is not mounted resize2fs -P ...partition.path... https://github.com/GNOME/gparted/blob/master/src/fat16.cc#L129 uses fsck.fat -n -v ...partition.path... or if that is not present dosfsck -n -v ...partition.path... The Gparted C++ code then looks for particular text snippets in the output of the programs in order to read the numbers which follow. One may suck more hints from the programmers' comments in the lines which begin by "//". Have a nice day :) Thomas
Re: Partition information as text file?
On 01/30/2019 10:04 AM, Joe wrote: [snip] I suspect that to get exactly what you want, you will need to write a script that uses basic tools, checking for mounted filesystems and then temporarily mounting as necessary. Yes ;} But before this thread I didn't have needed background. By the way, you haven't mentioned LVM... I'm working with a conglomeration created before I ever hear of LVM. I suspect I was on the way to (re)inventing it.
Re: Partition information as text file?
On 01/29/2019 10:16 AM, Thomas Schmitt wrote: Hi, Richard Owlett wrote: Gparted displays the desired data in the GUI, but I see no way to get that information as a text stream. Well, it seems to inquire the info by filesystem specific means. The method is obviously named set_used_sectors(). See e.g. https://github.com/GNOME/gparted/blob/master/src/ext2.cc#L147 https://github.com/GNOME/gparted/blob/master/src/fat16.cc#L129 https://github.com/GNOME/gparted/blob/master/src/xfs.cc#L89 There are several source files from btrfs.cc to xfs.cc. One could harvest hints about which man pages to read in order to create some program which knows the inquiry commands for all filesystems which Gparted knows. (I dimly remember to have seen such inquiry/management program names in replies to this thread.) Though I not a C programmer, their organization leads to answers for my questions [even a few I hadn't asked]. They create an interesting homework assignment. "If retirement isn't for learning, what use is it?" Thank you.
Re: Talking about loop devices (was: Re: Partition information as text file?)
On Thu, Jan 31, 2019 at 12:15:58PM +1100, David wrote: > On Thu, 31 Jan 2019 at 02:52, wrote: > > > > [...] > > > >A plain regular file can be made available as a device > >via the loopback driver > > I have a small addition to this excellent message. > > There is very widespread mixup of the terms "loopback" > and "loop" in the context of block devices. You are right: what I referred to as "loopback" device is known as a "loop" device. Thanks for the clarification. Cheers -- t signature.asc Description: Digital signature
Re: Talking about loop devices (was: Re: Partition information as text file?)
On Thu, 31 Jan 2019 at 12:15, David wrote: > > So all but one instance has changed from "loopback" to > "loop" ... maybe someone did a case-sensitive search/replace? :) Well, I found where that change happened, in 2006: https://github.com/torvalds/linux/commit/11420211b8123d0e2f71945ad022e8eec28ebfce But that's not very enlightening, because the file that the commit message mentions as the reason for the changes http://www.lanana.org/docs/device-list/devices-2.6+.txt today says "loopback" there. So, I dunno :(
Talking about loop devices (was: Re: Partition information as text file?)
On Thu, 31 Jan 2019 at 02:52, wrote: > > [...] > >A plain regular file can be made available as a device >via the loopback driver I have a small addition to this excellent message. There is very widespread mixup of the terms "loopback" and "loop" in the context of block devices. I've written about this in the past here. I will do my best to be correct, and give evidence, although 1) I wish I had more evidence 2) I can't remember when I first became aware of this 3) I have very little knowledge of kernel development ... A *loop* device is a *filesystem* technique to make a file accessible as a block device. Whereas a *loopback* device is a virtual *network* interface. The word "loopback" does not appear in 'man mount'. https://en.wikipedia.org/wiki/Loop_device says: "Sometimes, the loop device is erroneously referred to as loopback device, but this term is reserved for a networking device in operating systems." Unfortunately I cannot remember where this first came to my attention, so I can't provide a better authoritative reference. There must be one in existence out there somewhere, because I'm certain I didn't invent this myself, so I must have read about it somewhere. And I vaguely recall reading that some attempts were made to correct this in the kernel source. Today I tried to find some evidence of that ... For example, back in 2005 (linux 2.6.12) says: https://github.com/torvalds/linux/commit/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 - begin quote - 7 block Loopback devices 0 = /dev/loop0 First loopback device 1 = /dev/loop1 Second loopback device ... The loopback devices are used to mount filesystems not associated with block devices. The binding to the loopback devices is handled by mount(8) or losetup(8). - end quote - "loopback" is everywhere there! Compare with today's version: https://github.com/torvalds/linux/blob/v4.19/Documentation/admin-guide/devices.txt#L191 - begin quote - 7 block Loopback devices 0 = /dev/loop0 First loop device 1 = /dev/loop1 Second loop device ... The loop devices are used to mount filesystems not associated with block devices. The binding to the loop devices is handled by mount(8) or losetup(8). - end quote - So all but one instance has changed from "loopback" to "loop" ... maybe someone did a case-sensitive search/replace? :) Searching the kernel source for the word "loopback" here: https://livegrep.com/search/linux?q=loopback_case=auto=false=false shows that, when referring to block devices, the word "loopback" only appears in documentation here and there, never in code. The actual driver code is here: https://github.com/torvalds/linux/blob/v4.19/drivers/block/loop.c $ grep -c -i loopback loop.c 2 $ grep -c -i loop loop.c 343 The concept of "loopback" doesn't seem relevant to a loop device. It's just a filesystem in a file, isn't it? I suppose that's a slightly recursive concept, but it's not circular like a loop. To me, the word "loopback" suggests that something is going around and coming back again. I don't see how that is relevant to a loop device. Comments welcome. Maybe Ted Ts'o will read this and enlighten us (me).
Re: Partition information as text file?
Le 30/01/2019 à 16:07, Richard Owlett a écrit : On 01/29/2019 02:08 PM, Pascal Hambourg wrote: Le 29/01/2019 à 15:30, Richard Owlett a écrit : all my disks have "msdos Partition table". Irrelevant. Debian thought it relevant enough to mention in a warning(error?) message. Not Debian. Just tune2fs, as a hint suggesting that maybe you specified the wrong device. I get the following error message: root@fromdell:/home/richard# tune2fs -l /dev/sda tune2fs 1.43.4 (31-Jan-2017) tune2fs: Bad magic number in super-block while trying to open /dev/sda Found a dos partition table in /dev/sda You must specify the partition containing the filesystem, not the whole disk. The man pages for fdisk, parted, sfdisk, tune2fs, and dumpe2fs each give "device" as a possible parameter. Only the last two balk at it. "Device" is in the generic sense of Unix block device. Not just a whole disk, but also a partition, logical volume, RAID array, encrypted volume... fdisk, parted and sfdisk manage partition tables and expect a device containing a partition table. tune2fs and dumpe2fs manage ext* filesystems and expect a device containing an ext* filesystem.
Re: Partition information as text file?
On Wed, 30 Jan 2019 09:07:37 -0600 Richard Owlett wrote: > > > >> I get the following error message: > >>> root@fromdell:/home/richard# tune2fs -l /dev/sda > >>> tune2fs 1.43.4 (31-Jan-2017) > >>> tune2fs: Bad magic number in super-block while trying to > >>> open /dev/sda Found a dos partition table in /dev/sda > > > > You must specify the partition containing the filesystem, not the > > whole disk. > > The man pages for fdisk, parted, sfdisk, tune2fs, and dumpe2fs each > give "device" as a possible parameter. Only the last two balk at it. > > > On *some* devices. Not all devices have partition tables. I've seen a few USB sticks come formatted without a partition table, which strangely, *almost* works. Some software can deal with it, some can't. I first encountered it when using one to move data between OSes, and it took me a while to figure out what was going on. I'm sure you've realised by now, your requirement is to extract information from two different types of object, partitions and filesystems. That requires two different utilities. Apparently GParted will make a stab at displaying free space on unmounted filesystems, but it either does that by temporarily mounting them or it interprets the metadata of the filesystem itself, with no guarantee that it always gets it right. An unmounted filesystem is basically, well, gibberish, a collection of tables and file fragments. It's only when the filesystem is mounted that the parts of it that we mortals are allowed to see make sense. I suspect that to get exactly what you want, you will need to write a script that uses basic tools, checking for mounted filesystems and then temporarily mounting as necessary. By the way, you haven't mentioned LVM... -- Joe
Re: Partition information as text file?
On Wed, Jan 30, 2019 at 09:07:37AM -0600, Richard Owlett wrote: [...] > The man pages for fdisk, parted, sfdisk, tune2fs, and dumpe2fs each > give "device" as a possible parameter. Only the last two balk at it. This is as if you said that a fillet knife and a nutcracker both specify "food" as a possible parameter. But expect the cook to kick you out of the kitchen if you try to crack a nut with the fillet knife (although you might succeed at it). As a toolsguy this should be familiar to you. The last two expect a "device" (which is just a kind of file, you can do all of that with a bog standard file, everything which can be seen as a long series of blocks is fair game) _containing_ an ext2 file system (actually they most probably look first at the header to check this). - (block) device file: (e.g. /dev/sdb) a contraption of your operating system making a storage device available as a file of sorts, to ease the lives of many utilities - partition: a part of a block device. Usually (you don't _have_ to), a storage device is subdivided into several partitions. This subdivision is documented in the partition table (which can be the oldskool DOS partition table with the well-known limitations of 4 viz. 3+4 partitions or a more modern GPT or some others living out there). Usually this partition table is written as a data structure somewhere at the start of the storage device (and thus at the first block(s) of the device file). A partition is usually made available as a device file too (e.g. /dev/sdb1) A plain regular file can be made available as a device via the loopback driver (this is useful for virtual machines, but also for experiments -- e.g. I work on a file "image" for my Raspi which I can mount and look into with my laptop. When I'm happy I just dump it to an SD card. - file system: the whole machinery needed to organize your data whithin a huge unstructured pool of blocks. There are many constraints on a file system, like efficient space usage, quick allocation of new files, contiguous allocation of space (whenever possible) for a file (this is most important for mechanical drives), etc. There are many different file systems, in response to many different requirements and historical roots. You typically "put" a file system on a device file (the storage behind that is the "backend"), be it a device, a partition, a logical volume or a loopback on a regular file: the file system code doesn't care, as long as it sees a long, boring array of blocks, all alike. Clearer now? Cheers -- t signature.asc Description: Digital signature
Re: Partition information as text file?
On 01/29/2019 08:05 PM, David wrote: On Wed, 30 Jan 2019 at 01:30, Richard Owlett wrote: ... [https://dyn.manpages.debian.org/jump?suite=stretch=dosfstools=8=en=fsck.dos] yields "Sorry, the manpage “fsck.dos” was not found!" In case you are not aware, here's a way to investigate that ... $ apt-file search fsck.dos gave no output, so I broadened the net ... $ apt-file search fsck | grep dos ... I wasn't aware. Thank you.
Re: Partition information as text file?
On 01/29/2019 02:08 PM, Pascal Hambourg wrote: Le 29/01/2019 à 15:30, Richard Owlett a écrit : On 01/28/2019 01:43 PM, Pascal Hambourg wrote: The total and used/free space in ext and FAT filesystems can be computed from the output of tune2fs -l/dumpe2fs -h and fsck.dos -n. all my disks have "msdos Partition table". Irrelevant. Debian thought it relevant enough to mention in a warning(error?) message. There I thought it reasonable that it was true of _all_ my disks. I get the following error message: root@fromdell:/home/richard# tune2fs -l /dev/sda tune2fs 1.43.4 (31-Jan-2017) tune2fs: Bad magic number in super-block while trying to open /dev/sda Found a dos partition table in /dev/sda You must specify the partition containing the filesystem, not the whole disk. The man pages for fdisk, parted, sfdisk, tune2fs, and dumpe2fs each give "device" as a possible parameter. Only the last two balk at it.
Re: Partition information as text file?
On Wed, 30 Jan 2019 at 01:30, Richard Owlett wrote: > On 01/28/2019 01:43 PM, Pascal Hambourg wrote: > > > > The total and used/free space in ext and FAT filesystems can be computed > > from the output of tune2fs -l/dumpe2fs -h and fsck.dos -n. > > I assume "fsck.dos" is a typo as > [https://dyn.manpages.debian.org/jump?suite=stretch=dosfstools=8=en=fsck.dos] > yields > "Sorry, the manpage “fsck.dos” was not found!" In case you are not aware, here's a way to investigate that ... $ apt-file search fsck.dos gave no output, so I broadened the net ... $ apt-file search fsck | grep dos dosfstools: /sbin/dosfsck dosfstools: /sbin/fsck.fat dosfstools: /sbin/fsck.msdos dosfstools: /sbin/fsck.vfat dosfstools: /usr/share/doc/dosfstools/ChangeLog.dosfsck dosfstools: /usr/share/doc/dosfstools/README.dosfsck dosfstools: /usr/share/man/man8/dosfsck.8.gz dosfstools: /usr/share/man/man8/fsck.fat.8.gz dosfstools: /usr/share/man/man8/fsck.msdos.8.gz dosfstools: /usr/share/man/man8/fsck.vfat.8.gz manpages-fr-extra: /usr/share/man/fr/man8/dosfsck.8.gz manpages-fr-extra: /usr/share/man/fr/man8/fsck.msdos.8.gz manpages-pl: /usr/share/man/pl/man8/dosfsck.8.gz manpages-pl: /usr/share/man/pl/man8/fsck.msdos.8.gz Maybe it's a typo mixup of 'dosfsck' and 'fsck.msdos', which are both symlinks to the same executable ... $ ls -l /sbin/dosfsck lrwxrwxrwx 1 root root 8 2017-01-25 10:48 /sbin/dosfsck -> fsck.fat $ ls -l /sbin/fsck.msdos lrwxrwxrwx 1 root root 8 2017-01-25 10:48 /sbin/fsck.msdos -> fsck.fat
Re: Partition information as text file?
Le 29/01/2019 à 15:30, Richard Owlett a écrit : On 01/28/2019 01:43 PM, Pascal Hambourg wrote: The total and used/free space in ext and FAT filesystems can be computed from the output of tune2fs -l/dumpe2fs -h and fsck.dos -n. all my disks have "msdos Partition table". Irrelevant. I get the following error message: root@fromdell:/home/richard# tune2fs -l /dev/sda tune2fs 1.43.4 (31-Jan-2017) tune2fs: Bad magic number in super-block while trying to open /dev/sda Found a dos partition table in /dev/sda You must specify the partition containing the filesystem, not the whole disk. Additionally, all my machines have legacy BIOS. Irrelevant. I assume "fsck.dos" is a typo as Yes, my mistake. I meant fsck.fat or fsck.msdos.
Re: Partition information as text file?
On Mon 28 Jan 2019 at 06:48:00 (-0600), Richard Owlett wrote: > On 01/27/2019 03:26 PM, David Wright wrote: > > On Sat 26 Jan 2019 at 15:10:55 (-0600), Richard Owlett wrote: > > > On 01/26/2019 01:32 PM, Felix Miata wrote: > > > > Richard Owlett composed on 2019-01-26 08:32 (UTC-0600): > > > > > > > > > I am attempting to create a spreadsheet to document the content of > > > > > multiple disks of multiple machines. > > > > > > > > > Gparted displays the desired information. > > > > > *HOWEVER* I see no way to capture the information. > > > > > > > > > At the command line using "lsblk -o NAME,FSTYPE,LABEL /dev/sdb" gives > > > > > most of the desired information. > > > > > > > > > It omits partition size, used space, and unused space. > > > > > > > > > Suggestions? > > […] > > > > Sometimes I append output from lsblk or parted -l. > > > > > > > > hdparm and smartctl might also provide some of what you're looking for. > > > > > > I'll attempt to redefine my problem. > > > > > > I have: > > >multiple machines > > > each having > > >multiple disks > > > each having > > >multiple partitions. > > > > > > I wish to inventory the above "conglomeration". > > > > > > I wish to to answer the question(s): > > >How big is each > > >How much is available > > > > It appears that you're really interested in the filesystems' > > information rather than the partitions', with the exception of the > > filesystem LABELs, which you have said elsewhere you use as > > indications of the filesystems' contents. > > That's likely. There are some terminology issues I'll have to follow > up on so that I'll use terms in ways compatible to others. > > > > > So it looks as if df --output -x tmpfs -x devtmpfs gives you all > > you want (and more) with the exception of LABELs. > > No. The man pages states it only looks at mounted partitions due to > "...nonportable intimate knowledge of file system structures]. Then mount them. As readonly if preferred. > As I > only have FAT and ext partitions, what I want should be doable if not > already done. Then do it. All the tools are in the thread, if not in this post. > > It seems sensible > > to use lsblk -o NAME,LABEL -l to get these because AFAICT it > > automatically handles the business of selecting e2label/dosfslabel/etc > > as appropriate and gets them all in a heap. > > > > With judicious use of head, tail and sort, it would be fairly simple > > to get the two listings to correspond well enough for entry into a > > spreadsheet (I don't know what you meant by 'generic'), making > > final adjustments (df omits the device and partitions like swap) to > > line things up. > > I'm going to have to reread this thread. There is something in the > back of mind hinting at a solution. It will require some scripting to > pull pieces together, but that was assumed to be likely anyway. BTW you could read man man. Cheers, David.
Re: Partition information as text file?
On Tue, 29 Jan 2019, Richard Owlett wrote: > Date: Tue, 29 Jan 2019 10:22:42 > From: Richard Owlett > To: debian-user@lists.debian.org > Subject: Re: Partition information as text file? > Resent-Date: Tue, 29 Jan 2019 15:23:04 + (UTC) > Resent-From: debian-user@lists.debian.org > > On 01/29/2019 08:37 AM, to...@tuxteam.de wrote: > > On Tue, Jan 29, 2019 at 08:30:13AM -0600, Richard Owlett wrote: > > > >> I assume "fsck.dos" is a typo as > >> [https://dyn.manpages.debian.org/jump?suite=stretch=dosfstools=8=en=fsck.dos] > >> yields > >> "Sorry, the manpage ?fsck.dos? was not found!" > > > > You have the manpages on your box, hopefully. Try "man -k fsck", and you'll > > get: > > [snip sample output] > > I avoid using "man" as I find the HTML of online pages friendlier. Also in the > past I was reading man pages more frequently to chose whether or not to > install a particular package than to explore what an installed package could > do for me. > > I didn't know of the "-k" option. I haven't come across an equivalent function > online. I may not use "man" to read, but "man -k" should be very useful for > deciding which online pages I wish to read. > > > > > So I'd try fsck.fat or similar (/if/ it has to be fat, that is) > > > >> Thanks for trying. > > > > That's how we advance, after all :) > > > >> What bugs me is Gparted [though it does not output text] reports > >> used/unused space on each partition/file system. > > > > I can't grok this one: shouldn't gparted report on it? Or you don't > > expect the free space to be there? > > Gparted displays the desired data in the GUI, but I see no way to get that > information as a text stream. I need a text file for my application. > > Thanks > clipit may be able to snag this information for you then dump it to a text file for you. Not as elegant as a script though. > > > > --
Re: Partition information as text file?
+1 On 1/29/19 7:22 AM, Richard Owlett wrote: Gparted displays the desired data in the GUI, but I see no way to get that information as a text stream. I need a text file
Re: Partition information as text file?
Hi, Richard Owlett wrote: > Gparted displays the desired data in the GUI, but I see no way to get that > information as a text stream. Well, it seems to inquire the info by filesystem specific means. The method is obviously named set_used_sectors(). See e.g. https://github.com/GNOME/gparted/blob/master/src/ext2.cc#L147 https://github.com/GNOME/gparted/blob/master/src/fat16.cc#L129 https://github.com/GNOME/gparted/blob/master/src/xfs.cc#L89 There are several source files from btrfs.cc to xfs.cc. One could harvest hints about which man pages to read in order to create some program which knows the inquiry commands for all filesystems which Gparted knows. (I dimly remember to have seen such inquiry/management program names in replies to this thread.) Have a nice day :) Thomas
Re: Partition information as text file?
On Tue, Jan 29, 2019 at 09:22:42AM -0600, Richard Owlett wrote: > On 01/29/2019 08:37 AM, to...@tuxteam.de wrote: > >On Tue, Jan 29, 2019 at 08:30:13AM -0600, Richard Owlett wrote: > > > >>I assume "fsck.dos" is a typo as > >>[https://dyn.manpages.debian.org/jump?suite=stretch=dosfstools=8=en=fsck.dos] > >> yields > >>"Sorry, the manpage “fsck.dos” was not found!" > > > >You have the manpages on your box, hopefully. Try "man -k fsck", and you'll > >get: > >[snip sample output] > > I avoid using "man" as I find the HTML of online pages friendlier. Mileages tend to vary wildly. Me, I don't like HTML very much. The heavy handed markup tends to interfere with the "text-ness" I appreciate in documentation. > Also in the past I was reading man pages more frequently to chose > whether or not to install a particular package than to explore what > an installed package could do for me. > > I didn't know of the "-k" option. I haven't come across an > equivalent function online. I may not use "man" to read, but "man > -k" should be very useful for deciding which online pages I wish to > read. See also "apropos". > >>What bugs me is Gparted [though it does not output text] reports > >>used/unused space on each partition/file system. > > > >I can't grok this one: shouldn't gparted report on it? Or you don't > >expect the free space to be there? > > Gparted displays the desired data in the GUI, but I see no way to > get that information as a text stream. I need a text file for my > application. Aha. Now I understood. But am not versed enough in gparted to be able to help you :-/ Cheers -- t signature.asc Description: Digital signature
Re: Partition information as text file?
On 01/29/2019 08:37 AM, to...@tuxteam.de wrote: On Tue, Jan 29, 2019 at 08:30:13AM -0600, Richard Owlett wrote: I assume "fsck.dos" is a typo as [https://dyn.manpages.debian.org/jump?suite=stretch=dosfstools=8=en=fsck.dos] yields "Sorry, the manpage “fsck.dos” was not found!" You have the manpages on your box, hopefully. Try "man -k fsck", and you'll get: [snip sample output] I avoid using "man" as I find the HTML of online pages friendlier. Also in the past I was reading man pages more frequently to chose whether or not to install a particular package than to explore what an installed package could do for me. I didn't know of the "-k" option. I haven't come across an equivalent function online. I may not use "man" to read, but "man -k" should be very useful for deciding which online pages I wish to read. So I'd try fsck.fat or similar (/if/ it has to be fat, that is) Thanks for trying. That's how we advance, after all :) What bugs me is Gparted [though it does not output text] reports used/unused space on each partition/file system. I can't grok this one: shouldn't gparted report on it? Or you don't expect the free space to be there? Gparted displays the desired data in the GUI, but I see no way to get that information as a text stream. I need a text file for my application. Thanks
Re: Partition information as text file?
On Tue, Jan 29, 2019 at 08:30:13AM -0600, Richard Owlett wrote: > I assume "fsck.dos" is a typo as > [https://dyn.manpages.debian.org/jump?suite=stretch=dosfstools=8=en=fsck.dos] > yields > "Sorry, the manpage “fsck.dos” was not found!" You have the manpages on your box, hopefully. Try "man -k fsck", and you'll get: tomas@trotzki:~$ man -k fsck dosfsck (8) - check and repair MS-DOS filesystems e2fsck (8) - check a Linux ext2/ext3/ext4 file system e2fsck.conf (5) - Configuration file for e2fsck exfatfsck (8)- check an exFAT file system fsck (8) - check and repair a Linux filesystem fsck.cramfs (8) - fsck compressed ROM file system fsck.exfat (8) - check an exFAT file system fsck.ext2 (8)- check a Linux ext2/ext3/ext4 file system fsck.ext3 (8)- check a Linux ext2/ext3/ext4 file system fsck.ext4 (8)- check a Linux ext2/ext3/ext4 file system fsck.fat (8) - check and repair MS-DOS filesystems fsck.hfs (8) - HFS file system consistency check fsck.hfsplus (8) - HFS file system consistency check fsck.minix (8) - check consistency of Minix filesystem fsck.msdos (8) - check and repair MS-DOS filesystems fsck.nfs (8) - Dummy fsck.nfs script that always returns success. fsck.vfat (8)- check and repair MS-DOS filesystems git-fsck (1) - Verifies the connectivity and validity of the objects in the database git-fsck-objects (1) - Verifies the connectivity and validity of the objects in the database hpfsck (1) - check integrity of an HFS+ volume So I'd try fsck.fat or similar (/if/ it has to be fat, that is) > Thanks for trying. That's how we advance, after all :) > What bugs me is Gparted [though it does not output text] reports > used/unused space on each partition/file system. I can't grok this one: shouldn't gparted report on it? Or you don't expect the free space to be there? Cheers -- t > > > > > > > signature.asc Description: Digital signature
Re: Partition information as text file?
On 01/28/2019 01:43 PM, Pascal Hambourg wrote: Le 28/01/2019 à 13:48, Richard Owlett a écrit : So it looks as if df --output -x tmpfs -x devtmpfs gives you all you want (and more) with the exception of LABELs. No. The man pages states it only looks at mounted partitions due to "...nonportable intimate knowledge of file system structures]. As I only have FAT and ext partitions, what I want should be doable if not already done. The total and used/free space in ext and FAT filesystems can be computed from the output of tune2fs -l/dumpe2fs -h and fsck.dos -n. Murphy's Law has won this round, all my disks have "msdos Partition table". I get the following error message: root@fromdell:/home/richard# tune2fs -l /dev/sda tune2fs 1.43.4 (31-Jan-2017) tune2fs: Bad magic number in super-block while trying to open /dev/sda Found a dos partition table in /dev/sda Additionally, all my machines have legacy BIOS. I assume "fsck.dos" is a typo as [https://dyn.manpages.debian.org/jump?suite=stretch=dosfstools=8=en=fsck.dos] yields "Sorry, the manpage “fsck.dos” was not found!" Thanks for trying. What bugs me is Gparted [though it does not output text] reports used/unused space on each partition/file system.
Re: Partition information as text file?
Le 28/01/2019 à 13:48, Richard Owlett a écrit : So it looks as if df --output -x tmpfs -x devtmpfs gives you all you want (and more) with the exception of LABELs. No. The man pages states it only looks at mounted partitions due to "...nonportable intimate knowledge of file system structures]. As I only have FAT and ext partitions, what I want should be doable if not already done. The total and used/free space in ext and FAT filesystems can be computed from the output of tune2fs -l/dumpe2fs -h and fsck.dos -n.
Re: Partition information as text file?
On 28-01-2019, at 06h 48'00", Richard Owlett wrote about "Re: Partition information as text file?" > On 01/27/2019 03:26 PM, David Wright wrote: > >On Sat 26 Jan 2019 at 15:10:55 (-0600), Richard Owlett wrote: > >>On 01/26/2019 01:32 PM, Felix Miata wrote: > >>>Richard Owlett composed on 2019-01-26 08:32 (UTC-0600): > >>> > >>>>I am attempting to create a spreadsheet to document the content of > >>>>multiple disks of multiple machines. > >>> You know, gparted is based on parted, that is text based. Also use fdisk, skdisk, etc. that are text based. You redirect their output into a text file that you can use in your spread sheet program (whatever that can be). For example fdisk -l (as root) will output all partitions on all disks from a system. You can grep it, pipe it to sed to modify stuff, awk to play with columns, etc. to make it look like you please. If you can ssh to those machine, you can do it like this: for m in machine1 machine2 machine3 ; do ssh $m fdisk -l done > file_with_all_partition_info_machines_1-3.txt If you plan to use that info to recreate partitions, use the dump version of sfdisk: sfdisk -d /dev/sda > sfdisk_dump_sda.txt that you can use to make those partitions to another drive: sfdisk /dev/sdX < sfdisk_dump_sda.txt If you want a graphical ouput, something along the lines of gparted, just grab the screen with import. I usually do this: sleep 3 ; import file.jpg on a terminal to make sure I have time to put the main window on focus for capturing. Ionel
Re: Partition information as text file?
On 01/27/2019 03:26 PM, David Wright wrote: On Sat 26 Jan 2019 at 15:10:55 (-0600), Richard Owlett wrote: On 01/26/2019 01:32 PM, Felix Miata wrote: Richard Owlett composed on 2019-01-26 08:32 (UTC-0600): I am attempting to create a spreadsheet to document the content of multiple disks of multiple machines. Gparted displays the desired information. *HOWEVER* I see no way to capture the information. At the command line using "lsblk -o NAME,FSTYPE,LABEL /dev/sdb" gives most of the desired information. It omits partition size, used space, and unused space. Suggestions? […] Sometimes I append output from lsblk or parted -l. hdparm and smartctl might also provide some of what you're looking for. I'll attempt to redefine my problem. I have: multiple machines each having multiple disks each having multiple partitions. I wish to inventory the above "conglomeration". I wish to to answer the question(s): How big is each How much is available It appears that you're really interested in the filesystems' information rather than the partitions', with the exception of the filesystem LABELs, which you have said elsewhere you use as indications of the filesystems' contents. That's likely. There are some terminology issues I'll have to follow up on so that I'll use terms in ways compatible to others. So it looks as if df --output -x tmpfs -x devtmpfs gives you all you want (and more) with the exception of LABELs. No. The man pages states it only looks at mounted partitions due to "...nonportable intimate knowledge of file system structures]. As I only have FAT and ext partitions, what I want should be doable if not already done. It seems sensible to use lsblk -o NAME,LABEL -l to get these because AFAICT it automatically handles the business of selecting e2label/dosfslabel/etc as appropriate and gets them all in a heap. With judicious use of head, tail and sort, it would be fairly simple to get the two listings to correspond well enough for entry into a spreadsheet (I don't know what you meant by 'generic'), making final adjustments (df omits the device and partitions like swap) to line things up. I'm going to have to reread this thread. There is something in the back of mind hinting at a solution. It will require some scripting to pull pieces together, but that was assumed to be likely anyway. Later.
Re: Partition information as text file?
On Sat 26 Jan 2019 at 15:10:55 (-0600), Richard Owlett wrote: > On 01/26/2019 01:32 PM, Felix Miata wrote: > > Richard Owlett composed on 2019-01-26 08:32 (UTC-0600): > > > > > I am attempting to create a spreadsheet to document the content of > > > multiple disks of multiple machines. > > > > > Gparted displays the desired information. > > > *HOWEVER* I see no way to capture the information. > > > > > At the command line using "lsblk -o NAME,FSTYPE,LABEL /dev/sdb" gives > > > most of the desired information. > > > > > It omits partition size, used space, and unused space. > > > > > Suggestions? […] > > Sometimes I append output from lsblk or parted -l. > > > > hdparm and smartctl might also provide some of what you're looking for. > > I'll attempt to redefine my problem. > > I have: > multiple machines > each having > multiple disks > each having > multiple partitions. > > I wish to inventory the above "conglomeration". > > I wish to to answer the question(s): > How big is each > How much is available It appears that you're really interested in the filesystems' information rather than the partitions', with the exception of the filesystem LABELs, which you have said elsewhere you use as indications of the filesystems' contents. So it looks as if df --output -x tmpfs -x devtmpfs gives you all you want (and more) with the exception of LABELs. It seems sensible to use lsblk -o NAME,LABEL -l to get these because AFAICT it automatically handles the business of selecting e2label/dosfslabel/etc as appropriate and gets them all in a heap. With judicious use of head, tail and sort, it would be fairly simple to get the two listings to correspond well enough for entry into a spreadsheet (I don't know what you meant by 'generic'), making final adjustments (df omits the device and partitions like swap) to line things up. > OWL now DUCKS fer cover ;/ No need. Cheers, David.
Re: Partition information as text file?
On 28/01/19 9:36 AM, Pascal Hambourg wrote: >>> Usually, all of a partition is used. If the partition contains a >>> filesystem, swap area, RAID member or LVM physical volume, these data >>> structures use all the partition space. >> >> Not necessarily - eg if you've extended the partition and not the >> filesystem, it doesn't. > > Of course there are exceptions. This is why I wrote "usually". > But this space is not accounted as available/free in the partition > table, nor is it accounted as used/unused in the filesystem. Gparted > would not display it. Unless it is a transient state, it is just wasted > space. I made the point because it might be useful, in this case or others, to detect such wasted space (eg by comparing the partition table with the filesystem metadata) Richard signature.asc Description: OpenPGP digital signature
Re: Partition information as text file?
Le 27/01/2019 à 21:08, Richard Hector a écrit : On 27/01/19 4:45 AM, Pascal Hambourg wrote: Le 26/01/2019 à 16:12, Richard Owlett a écrit : But I still need to know how much of each partition is used/unused. Usually, all of a partition is used. If the partition contains a filesystem, swap area, RAID member or LVM physical volume, these data structures use all the partition space. Not necessarily - eg if you've extended the partition and not the filesystem, it doesn't. Of course there are exceptions. This is why I wrote "usually". But this space is not accounted as available/free in the partition table, nor is it accounted as used/unused in the filesystem. Gparted would not display it. Unless it is a transient state, it is just wasted space. It's probably possible to specify the fs size at creation time, too Yes, some filesystem creation tools allow to specify the size.
Re: Partition information as text file?
On 27/01/19 4:45 AM, Pascal Hambourg wrote: > Le 26/01/2019 à 16:12, Richard Owlett a écrit : >> On 01/26/2019 08:36 AM, Jude DaShiell wrote: >>> lsblk >>lsblk.txt >> >> I had misinterpreted "SIZE size of the device" in the response >> to "lsblk --help". I did not equate "device" to "partition". >> >> But I still need to know how much of each partition is used/unused. > > Usually, all of a partition is used. If the partition contains a > filesystem, swap area, RAID member or LVM physical volume, these data > structures use all the partition space. Not necessarily - eg if you've extended the partition and not the filesystem, it doesn't. Or if you've shrunk the filesystem and not the partition. It's probably possible to specify the fs size at creation time, too, but I've never come across a need for that. Richard signature.asc Description: OpenPGP digital signature
Re: Partition information as text file?
Richard Owlett composed on 2019-01-26 15:10 (UTC-0600): > Felix Miata wrote: >> Richard Owlett composed on 2019-01-26 08:32 (UTC-0600): >> I don't use a spreadsheet. > I was using "spreadsheet" in the most possible generic way ;/ >> http://fm.no-ip.com/Tmp/Dfsee/ >> http://fm.no-ip.com/Tmp/Dfsee/gb250L04.txt is from GPT partitioning for UEFI. > I _quickly_ browsed those sites. > I don't think they were attempting to *ANSWER* "my questions". Those other than gb250L04.txt were examples of the realities reported by the logging processes, while gb250L04.txt is one of the log remainders kept that comprise my actual inventory. That directory is not my actual inventory. > I'll attempt to redefine my problem. > I have: >multiple machines As I, >25. > each having >multiple disks Most of mine have but one. With three exceptions, those with more than one have more than one because of RAID. > each having >multiple partitions. Two of mine have more than 50, several more than 40, most between 12 and 30. > I wish to inventory the above "conglomeration". > I wish to to answer the question(s): >How big is each >How much is available What's missing in what I keep is freespace available on filesystems, which I don't try to keep track of, but the tool I use probably could include that as well. Unpartitioned space is as obvious as partition sizes. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Partition information as text file?
On 27.01.2019 2:10, Richard Owlett wrote: > On 01/26/2019 01:32 PM, Felix Miata wrote: >> Richard Owlett composed on 2019-01-26 08:32 (UTC-0600): >> >>> I am attempting to create a spreadsheet to document the content of >>> multiple disks of multiple machines. >> >>> Gparted displays the desired information. >>> *HOWEVER* I see no way to capture the information. >> >>> At the command line using "lsblk -o NAME,FSTYPE,LABEL /dev/sdb" gives >>> most of the desired information. >> >>> It omits partition size, used space, and unused space. >> >>> Suggestions? >> >> I don't use a spreadsheet. > > I was using "spreadsheet" in the most possible generic way ;/ > >> I use the logs automatically created by the non-FOSS >> partitioner I use, DFSee. > > My goal is more "report on reality" rather than "create a reality". > >> Various examples of its logs are here: >> >> http://fm.no-ip.com/Tmp/Dfsee/ >> >> http://fm.no-ip.com/Tmp/Dfsee/gb250L04.txt is from GPT partitioning >> for UEFI. > > I _quickly_ browsed those sites. > I don't think they were attempting to *ANSWER* "my questions". > >> >> The gb250 is the hostname. The L04 is serialization of the report's >> creation. It's >> content is reduced to that which I find useful data for tracking >> what's where among >> my 100+ disks. >> >> Sometimes I append output from lsblk or parted -l. >> >> hdparm and smartctl might also provide some of what you're looking for. >> > > I'll attempt to redefine my problem. > > I have: > multiple machines > each having > multiple disks > each having > multiple partitions. > > I wish to inventory the above "conglomeration". > > I wish to to answer the question(s): > How big is each > How much is available > > OWL now DUCKS fer cover ;/ > > Maybe some non-standard utility will fulfill your needs? Try installing "inxi" and type: $ inxi -DRoplu It has many options and also different output settings. -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Re: Partition information as text file?
On 01/26/2019 01:32 PM, Felix Miata wrote: Richard Owlett composed on 2019-01-26 08:32 (UTC-0600): I am attempting to create a spreadsheet to document the content of multiple disks of multiple machines. Gparted displays the desired information. *HOWEVER* I see no way to capture the information. At the command line using "lsblk -o NAME,FSTYPE,LABEL /dev/sdb" gives most of the desired information. It omits partition size, used space, and unused space. Suggestions? I don't use a spreadsheet. I was using "spreadsheet" in the most possible generic way ;/ I use the logs automatically created by the non-FOSS partitioner I use, DFSee. My goal is more "report on reality" rather than "create a reality". Various examples of its logs are here: http://fm.no-ip.com/Tmp/Dfsee/ http://fm.no-ip.com/Tmp/Dfsee/gb250L04.txt is from GPT partitioning for UEFI. I _quickly_ browsed those sites. I don't think they were attempting to *ANSWER* "my questions". The gb250 is the hostname. The L04 is serialization of the report's creation. It's content is reduced to that which I find useful data for tracking what's where among my 100+ disks. Sometimes I append output from lsblk or parted -l. hdparm and smartctl might also provide some of what you're looking for. I'll attempt to redefine my problem. I have: multiple machines each having multiple disks each having multiple partitions. I wish to inventory the above "conglomeration". I wish to to answer the question(s): How big is each How much is available OWL now DUCKS fer cover ;/
Re: Partition information as text file?
Richard Owlett composed on 2019-01-26 08:32 (UTC-0600): > I am attempting to create a spreadsheet to document the content of > multiple disks of multiple machines. > Gparted displays the desired information. > *HOWEVER* I see no way to capture the information. > At the command line using "lsblk -o NAME,FSTYPE,LABEL /dev/sdb" gives > most of the desired information. > It omits partition size, used space, and unused space. > Suggestions? I don't use a spreadsheet. I use the logs automatically created by the non-FOSS partitioner I use, DFSee. Various examples of its logs are here: http://fm.no-ip.com/Tmp/Dfsee/ http://fm.no-ip.com/Tmp/Dfsee/gb250L04.txt is from GPT partitioning for UEFI. The gb250 is the hostname. The L04 is serialization of the report's creation. It's content is reduced to that which I find useful data for tracking what's where among my 100+ disks. Sometimes I append output from lsblk or parted -l. hdparm and smartctl might also provide some of what you're looking for. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Partition information as text file?
On Sat 26 Jan 2019 at 08:32:28 (-0600), Richard Owlett wrote: > I am attempting to create a spreadsheet to document the content of > multiple disks of multiple machines. > > Gparted displays the desired information. > *HOWEVER* I see no way to capture the information. > > At the command line using "lsblk -o NAME,FSTYPE,LABEL /dev/sdb" gives > most of the desired information. > > It omits partition size, used space, and unused space. > > Suggestions? Just remove the g[nome] from the command name. # parted -l Model: ATA ST500LX005-1CW16 (scsi) Disk /dev/sda: 500GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 1049kB 1050MB 1049MB ntfsBasic data partition hidden, diag 2 1050MB 1322MB 273MB fat32 EFI system partition boot, hidden, esp 3 1322MB 2371MB 1049MB fat32 Basic data partition hidden 4 2371MB 2505MB 134MB Microsoft reserved partition msftres 5 2505MB 178GB 175GB ntfsBasic data partition msftdata 6 178GB 220GB 41.9GB ext4Linux-A 7 220GB 262GB 41.9GB ext4Linux-B 8 262GB 452GB 191GB Linux-Home 9 452GB 452GB 8389kB Linux-BIOS-Boot bios_grub 10 452GB 457GB 4502MB linux-swap(v1) Linux-Swap 11 457GB 457GB 367MB ntfs hidden, diag 12 457GB 458GB 1074MB ntfsBasic data partition msftdata 13 458GB 485GB 26.8GB ntfsBasic data partition msftdata 14 485GB 500GB 15.1GB ntfsBasic data partition hidden, diag If you want a lot more information than is there, one method is: $ for j in /sys/class/block/* ; do udevadm info "$j" ; done | less but it will need parsing before you can can dump any of it in a spreadsheet. (And note that the output is not in sequence because of globbing.) Cheers, David.
Re: Partition information as text file?
Le 26/01/2019 à 17:28, Richard Owlett a écrit : On 01/26/2019 09:45 AM, Pascal Hambourg wrote: Le 26/01/2019 à 16:12, Richard Owlett a écrit : On 01/26/2019 08:36 AM, Jude DaShiell wrote: lsblk >>lsblk.txt I had misinterpreted "SIZE size of the device" in the response to "lsblk --help". I did not equate "device" to "partition". But I still need to know how much of each partition is used/unused. Usually, all of a partition is used. HUH?? Either we are using terms differently OR I'm weird OR both ; Probably. When you write "partition", you actually mean "filesystem". These are two distinct things. A partition is just a raw block device which does not know what is is used for. A filesystem is a data structure. I'm explicitly wish the information Gparted displays for each partition of a physical device. The column titles are "Partition", "File System", "Label", "Size", "Used", "Unused", and "Flags". I need all but the last as text. And Gparted has no problem displaying the information independent of being mounted or not. Yes it does. I have seen it display wrong size information about unmounted partitions.
Re: Partition information as text file?
On 01/26/2019 09:45 AM, Pascal Hambourg wrote: Le 26/01/2019 à 16:12, Richard Owlett a écrit : On 01/26/2019 08:36 AM, Jude DaShiell wrote: lsblk >>lsblk.txt I had misinterpreted "SIZE size of the device" in the response to "lsblk --help". I did not equate "device" to "partition". But I still need to know how much of each partition is used/unused. Usually, all of a partition is used. HUH?? Either we are using terms differently OR I'm weird OR both ; I'm explicitly wish the information Gparted displays for each partition of a physical device. The column titles are "Partition", "File System", "Label", "Size", "Used", "Unused", and "Flags". I need all but the last as text. And Gparted has no problem displaying the information independent of being mounted or not. If the partition contains a filesystem, swap area, RAID member or LVM physical volume, these data structures use all the partition space. How much of the space within the data structure is used is outside the scope of the partition level and requires tools specific to the data structure type. Note that df can show only the used space of mounted filesystems and is not always accurate (btrfs).
Re: Partition information as text file?
Le 26/01/2019 à 16:12, Richard Owlett a écrit : On 01/26/2019 08:36 AM, Jude DaShiell wrote: lsblk >>lsblk.txt I had misinterpreted "SIZE size of the device" in the response to "lsblk --help". I did not equate "device" to "partition". But I still need to know how much of each partition is used/unused. Usually, all of a partition is used. If the partition contains a filesystem, swap area, RAID member or LVM physical volume, these data structures use all the partition space. How much of the space within the data structure is used is outside the scope of the partition level and requires tools specific to the data structure type. Note that df can show only the used space of mounted filesystems and is not always accurate (btrfs).
Re: Partition information as text file?
On 01/26/2019 08:36 AM, Jude DaShiell wrote: lsblk >>lsblk.txt I had misinterpreted "SIZE size of the device" in the response to "lsblk --help". I did not equate "device" to "partition". But I still need to know how much of each partition is used/unused. On Sat, 26 Jan 2019, Richard Owlett wrote: Date: Sat, 26 Jan 2019 09:32:28 From: Richard Owlett To: debian-user Subject: Partition information as text file? Resent-Date: Sat, 26 Jan 2019 14:33:38 + (UTC) Resent-From: debian-user@lists.debian.org I am attempting to create a spreadsheet to document the content of multiple disks of multiple machines. Gparted displays the desired information. *HOWEVER* I see no way to capture the information. At the command line using "lsblk -o NAME,FSTYPE,LABEL /dev/sdb" gives most of the desired information. It omits partition size, used space, and unused space. Suggestions? TIA
Re: Partition information as text file?
I had misinterpreted "SIZE size of the device" in the response > to "lsblk --help". I did not equate "device" to "partition". > > But I still need to know how much of each partition is used/unused. > > Hi df -h gives you that info Filesystem Size Used Avail Use% Mounted on udev 1.5G 0 1.5G 0% /dev tmpfs 299M 4.6M 294M 2% /run /dev/sda1 28G 9.0G 18G 35% / Hope this helps Paul > -- Paul Sutton http://www.zleap.net https://www.linkedin.com/in/zleap/ Twitter : @zleap2018 signature.asc Description: OpenPGP digital signature
Re: Partition information as text file?
lsblk >>lsblk.txt On Sat, 26 Jan 2019, Richard Owlett wrote: > Date: Sat, 26 Jan 2019 09:32:28 > From: Richard Owlett > To: debian-user > Subject: Partition information as text file? > Resent-Date: Sat, 26 Jan 2019 14:33:38 + (UTC) > Resent-From: debian-user@lists.debian.org > > I am attempting to create a spreadsheet to document the content of multiple > disks of multiple machines. > > Gparted displays the desired information. > *HOWEVER* I see no way to capture the information. > > At the command line using "lsblk -o NAME,FSTYPE,LABEL /dev/sdb" gives most of > the desired information. > > It omits partition size, used space, and unused space. > > Suggestions? > TIA > > > --
