Moderators: kirk, jamesbond, p310don, JakeSFR, step, Forum moderators
Issue:
Requests:
Could the SAMBA utility "findsmb" not be excluded in future FATDOGs?
And should a GRUB2 utility become a part of FATDOG, now?
Continuing testing a very recent ISO dated 02Feb22
Clarity wrote:savefile=direct:device:sda7:Sessions
The path argument expects a path that includes the name of a savefile/dir, or in this case, a session SFS file.
So, something like this:
Code: Select all
savefile=direct:device:sda7:/Sessions/sessionshould read/create Sessions/multi-session-2022...sfs and so on.
Feek wrote:Code: Select all
savefile=direct:multi:device:sda7:/Sessions/:
That would work, too, but the SFS files will be named multi--2022...sfs, beacuse the name wasn't specified.
Clarity wrote:Could the SAMBA utility "findsmb" not be excluded in future FATDOGs?
The findsmb utility is small enough to be included in the base (4.5K), but the problem is that it's a Perl script and the main Perl pkg alone weights 11M. So, if Perl has to be installed anyway, so can be the full Samba pkg.
Clarity wrote:And should a GRUB2 utility become a part of FATDOG, now?
You mean Shinobar's Grub2config? I don't know, maybe? Has anyone tested it in Fatdog yet? Personally, I use Syslinux exclusively.
Clarity wrote:Continuing testing a very recent ISO dated 02Feb22
Thanks for testing!
Greetings!
I still use grub4dos, so would hope that if grub2 was added to Control Panel it was a addition rather than a replacement. I also still use ext2 for its greater simplicity/security benefits (yes I know journalling can be turned off to otherwise prevent relatively easy unwanted restoration of deleted files contents). With ext2 its quick and easy to shred your tax return on the laptop once copied/stored wherever so that if at some point the laptop is stolen there's less opportunity to gain personal details that might be used in a identity theft attack.
CAUTION: Note that shred relies on a very important assumption: that
the file system overwrites data in place. This is the traditional way
to do things, but many modern file system designs do not satisfy this
assumption. The following are examples of file systems on which shred
is not effective, or is not guaranteed to be effective in all file sys‐
tem modes:* log-structured or journaled file systems, such as those supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
The menu.lst file created by Sinobar's grub4dos app works with fatdog64. It will boot windows 10 as well,
but I'm not sure if the app itself will run in fatdog64 since I have an old hard disk that was used with an older puppy distro.
I don't use a uefi machine.
http://shinobar.server-on.net/puppy/pup ... v1.5.2.pet
____________________________________________________________
Code: Select all
savefile=direct:device:sda7:/Sessions/Thanks @Feek and @JakeSFR for this instruction. Your instructions for the above boot parameter fix, allows FATDOG to, now, find the FD session data for constructing the desktop.
o
o
o
SAVEFILE Argument Builder error
This leads to a problem that could/should be addressed in 'Savefile Argument Builder', where a drag-drop of the Sessions folder to the app does NOT yield an acceptable recommendation in the field below it in the utility. The error/bug is shown in this picture.
o
o
o
SAMBA
@JakeSFR I thank you, also, for the finding on why 'findsmb' is not included in the distro. The 11MB need for fuller SAMBA is a inconsequential on 64bit PCs or in an ISO content. Maybe the upcoming FATDOG could consider it as SAMBA brings so much use and the utilities are very helpful for myself and others coming to FATDOG from outside. I will create a FATDOG SAMBA addendum document (to @jamesbond 's HTML page) for elementary FD users and this command would be used within.
You guys are great!
Thanks @Step
Yes, but have you ever tested the SAMBA 'findsmb' utility. It is a mainline SAMBA utility and its performance is near instantaneous.
Give it a try to see it; if you have a PUP running/QEMU; aka Slacko64/FossaPUP64/etc. And it is really easy to understand. Have used these SAMBA utils for years.
BTW: findsmb does NOT take anything away from the clever 'SMB browser'. FINDSMB Is just really simple, REALLY FAST, and straightforward for instant knowledge of where you local LAN smb hosts reside; not to mention some/many people are familiar with it.
OK
but have you ever tested the SAMBA 'findsmb' utility. It is a mainline SAMBA utility and its performance is near instantaneous.
Give it a try to see it; if you have a PUP running/QEMU; aka Slacko64/FossaPUP64/etc. And it is really easy to understand. Have used these SAMBA utils for years.
I just tried it on Fatdog.
Code: Select all
# findsmb
*=DMB
+=LMB
IP ADDR NETBIOS NAME WORKGROUP/OS/VERSION
---------------------------------------------------------------------
192.168.0.1 ROUTER *[ WORKGROUP ]
BTW: findsmb does NOT take anything away from the clever 'SMB browser'. FINDSMB Is just really simple, REALLY FAST, and straightforward for instant knowledge of where you local LAN smb hosts reside; not to mention some/many people are familiar with it.
I believe you, thanks for sharing.
THIS IS NOT A REQUEST FOR ANY DEVELOPMENT. It is shared, here, as an idea to make things in our home LAN easy to find by their names.
BTW: the output of this command can be placed in the system's host file /etc/hosts such that LAN resources can be accessed on the local PC by the LAN PC's hostname rather than using the IP address. This is just another idea of using the output from 'findsmb'.
So for example, if a simple "hosts file update" script exist, it could use the findsmb output for additional benefit.
# cat /etc/hosts
127.0.0.1 localhost FATDOG_PC
192.168.0.1 ROUTER
#
Thus, if a simple utility added the output to the hosts file, a command like
mount -o password=woofwoof //ROUTER/NAS /localPC_mount-point is an easier thing to remember versus a hunt for the IP address to mount the resource. (YES, I know the router does not have a user or password of 'woofwoof', but you get the idea, I'm sure)
Thanks to EVERYONE, here, for assistance and understanding.
Skip the idea for hosts file update. My view, after thought, is my idea for a utility to update is flawed in shortsightedness: good for a one-time after boot, but sustaining, well ...
Clarity wrote: ↑Thu Mar 24, 2022 8:59 pmSAVEFILE Argument Builder error
This leads to a problem that could/should be addressed in 'Savefile Argument Builder', where a drag-drop of the Sessions folder to the app does NOT yield an acceptable recommendation in the field below it in the utility. The error/bug is shown in this picture.
It's not an error. SAB simply doesn't know anything about multisession, only about savefiles and savefolders. It supports only a subset of all available savefile= boot options.
So, when you DND a folder into it, it assumes it's a savefolder and correctly assembles the appropriate boot arguments.
Anyway, I've added auto-detection of multisession, since it seems to be quite popular.
Attached. I feel it's on the verge of being confusing, but let's give it a try...
Greetings!
Thanks @JakeSFR .
I downloaded and replaced the existing 'builder'.
Should the DND OF /mnt/sda7/Sessions yield a parm of savefile=direct:device:sda7:/Sessions/? It is still showing the parm, same as the old savefile-argument builder.
@Clarity: note the 3rd point in the new builder: "3. Drag your savefile, savefolder or SFS into this box".
Greetings!
Thanks @JakeSFR, I did see that update.
Two question for creating the 'correct' argument:
Should the Multisession folder's base or the other folder within "/Sessions" be the one the user must drag to "3." field?
.
Or should FATDOG searching the /Sessions contents be enough for FD to find the available sesssion(s)?
Thanks in advance for your helping. @Jamesbond has indicated on an earlier thread on a different issue of some text changes for this utility.
Thanks, again, muchly.
Clarity wrote: ↑Wed Mar 30, 2022 7:04 amThanks @JakeSFR, I did see that update.
Two question for creating the 'correct' argument:
Should the Multisession folder's base or the other folder within "/Sessions" be the one the user must drag to "3." field?Sessions-Folder.png.
Or should FATDOG searching the /Sessions contents be enough for FD to find the available sesssion(s)?
Thanks in advance for your helping. @Jamesbond has indicated on an earlier thread on a different issue of some text changes for this utility.
Thanks, again, muchly.
Neither, just drag one of the SFSes, as the instruction states.
Btw, attached a new revision: the savefile argument was incorrect when an SFS was in the top-most directory.
Greetings!
Final testing on use of Savefile-Argument-Builder utility
It currently is NOT building a correct string for Multi-Session FATDOG use: The string that works for FATDOG to find the Multi-session saves that are contained in the Sessions folder is as follows:
savefile=ram:device:sda7:/Sessions/
OR
savefile=direct:device:sda7:/Sessions/
.
The Builder is not containing the folder in the REQUIRED "/" and instead builds an incorrect savefile=ram:device:sda7:Sessions which does not work for FATDOG to find the contained multi-session files.
Thus for multisession, the Builder needs to be updated to build correctly.
Edit: Next utility TEST shows this: Which IN FACT WORKS also!!! Before I was ONLY dragging the folder; namely ONLY ...Sessions to its field in the utility which created an incorrect sting. BUT, if I drag one of the Multi-session files to the field, instead, the result is this savefile=direct:multi:sda7:Sessions/Sessions. This parm yields the same behavior that the working parms I show.
The correct command for multisession is multi, not device.
If it worked for you with the latter, it's probably by some weird coincidence...
Also, when you drag a folder, you'll get the correct argument, but for a savefolder.
Ok, so the final conclusion is that it works, right?
Greetings!
Correct!
The utility does yield a correct boot parameter. Thanks 'eversomuch' for your guidance and resolutions in use of this utility and the parm needed for correct FATDOG ability.
And, in review of what you have done and what was also offered, earlier, manual use of either of the following works giving FATDOG instructions of where its "Multi-Session" info resides: as such, either will work! 2 Examples of the parms for finding FATDOGs sessions at boot time are:
savefile=direct:multi:sda7:Sessions/Sessions - from use of the utility
savefile=direct:multi:sda7:/Sessions/ - from an earlier correct recommendation
User, like myself, will prefer 'ram' vs 'direct'... both sub-options achieve proper session management.
Finding session files is much better understood.
FATDOG is excellent!
Great, thanks for testing!
One more revision, though.
I analyzed the system init script and it turned out that in addition to ...:multi:<dev>:... parameter, also ...:multi:device:<dev>:... and ...:multi:uuid:<uuid>:... constructs are accepted.
That info is not present in FAQ.
So, in the current revision only the last two are being produced, since the first one (multi:<dev>) is just a shorthand for the second one (multi:device:<dev>).
Greetings!