mavrothal wrote:@shinobar
Noticed that your shutdownconfig has "fido" inactivated. However I could not see any problem when reinstated. Is it because is not present in pupsaveconfig or somehow is incompatible with svefolder? (how?)
The current shutdownconfig in the woof offers 'fido', but says
'fido CURRENTLY EXPERIMENTAL STATUS, PLEASE CHOOSE Administrator'.
If you want to try 'fido', you can do it after, using the loginmanager.
In my opinion, the current 'fido' implementation has a problem in the fundamental design. 'fido' shold have /home/fido for its home.
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
Tried to add savefolder support in woof-CE but somehow it breaks gtk and all icons are gone form the desktop (no . gtk-update-icon-cache will not fix this).
Anyone has any idea why
(Attached the broken shutdowncofig for your convenience)
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
mavrothal wrote:Tried to add savefolder support in woof-CE but somehow it breaks gtk and all icons are gone form the desktop (no . gtk-update-icon-cache will not fix this).
Anyone has any idea why
(Attached the broken shutdowncofig for your convenience)
i have something want to say, but the shutdowncofig mavrothal showed fundamentally worked on the Tahr Puppy. I replaced /etc/rc.d/rc.shutdown with the one form gyro's 2014-06-06 ydrv, /usr/sbin/shutdownconfig with the one mavrothal showed(needed executable flag).
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]
shinobar wrote: I replaced /etc/rc.d/rc.shutdown with the one form gyro's 2014-06-06 ydrv,
That's what was missing
Thanks Latter: Fixed! So next puppy build from woof-CE testing will have savetofolder support
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
This just caught my attention as this seemingly allows 2 things that would be useful for any PUP user.
Using this utility ===> Here from @Gyro appears to open the way for 3 possible events:
resolving the "filled" save file by moving from a file to a folder within the same frugal folder location (insuring of course, that the user does NOT end with both a frugal save folder and a frugal save file).
to use this to take a frugal folder into a new base frugal folder thru this ability by exposing the contents into a folder along with exposing initrd and repacking initrd.
to convert a frugal install PUP to become a full installation with little effort.
You are right in looking for a single page which would describe the primary options available to Live users, and Frugal users, alike, when system shutdown would occur.
Your webpage may want to clarify by "Save-Session Options built into Puppy Linux". where the 'Introduction' explains that "... when running a Live boot or running a Frugal boot, the ability to save ones work during the session can be stored in either a Linux folder or buried in a Linux file."
Saving work we often done outside of the savefile/folder.
Here is the rewrite-
SaveFiles/ SaveFolder (also known as PupSave file/folder) are required for a Frugal Installation to save modifications to the operating system. The changes are either written written to RAM memory first then to file or folder, or written directly to file or folder. This method of running is sometimes referenced to as 'Live' in other distributions, where the option to make changes may or may not exist.
The changes are anything modifying, adding-to or removing-from the linux file structure (RootFS). This typically includes settings, installing new applications etc. It also includes anything saved in the ~ user directory (usually root).
The thread is closed but peebee found a bug and there is a fix to be tested before it makes it to woof-CE
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
there is issues using NTFS as savefolder since not all linux file flags are supported, however it doesn't seem to burst into flames Like I expected when I accidentally setup such an savefolder. A full install type ( copied all files from squashfs and made a dummy version to get better speed ) works great in linux filesystem save folders but lots of wierdness if done with NTFS.
I won't go there.
My motto is, leave NTFS partitions to Windows.
1) NTFS is propriety to Microsoft, they can change it, or how they use it, at any time. e.g. Windows 8 fastshudown/fastboot.
2) Since at least Windows 7 and still in Windows 10, there is a "Shrink Volume..." action in "Disk Manager" that can safely make available some unallocated disk space which can be used for a Linux filesystem.
with gyros advice ( and name gives me an idea for lunch ) do the resize early in the use of a new windows 8 or 10 machine BEFORE the bloat. It figures if its in a small space its on a SSD type hardware and removes a bunch of disk writing logs and keeps it self small as needed. I agressively sized my windows8.1 into less than 20G and it still runs as fine as windows can run ( I do not use it for much )
of course I already protected my windows HD with hybernate off and such.
For me I don't have a choice I have a mediabox that only uses NTFS and old MBR configurations so modified to work that way.
Is the LInux NTFS support coming from Microsoft? And, should we expect MS to shutdown the Linux link command as it is designed in Linux OR are you suggesting that some cleanup operation in MS, when running Windows could look for and destroy a Linux symbolic link?
At this point in the advancement of Windows (and Linux) and considering MS's position as a LInux user and contributor, I would not expect that particular-specific future change to occur. "Bad for business when MS has been showing a partnership with Linux/Unix."
I do understand what you share,@Gyro; but I don't feel that in today's world we shouldn't expect that occurrence/behavior from MS.
Their next filesystem change will probably be a new one, anyhow, depending on the direction of both mobile and datacenters are taking. That foundation is already afoot.
If we understand what today's NTFS provides in allowing Linux command links (and data) to exist in an NTFS environment, and that to survive over reboots, is there any reason that a session folder could also be expected to survive over reboots, same as occurs on on Linux partitions?
I cannot find any evidence that Linux links do not work. But, I may not be looking in the proper places that have current information.
Anyone know anything about the ability for save-session to survive with information unaltered and intact across reboots on a LInux system?
I am willing to test a save session change to determine if we can break the links that Linux would have it is filesystem across reboots....if a PET is available for testing.
Thoughts or information that anyone has/knows would be helpful.
P.S. Can the save session code that would allow saving to a NTFS partition be coded in such a way to make it easy to ID and remove if this idea is moved forward. Seems that it is already design to allow NTFS to be added as a detectable candidate same as the current Linux partitions. (take this comment with the understanding that I am NOT a bash anything, as I recognized how wrong I may be in visualizing the utility's design.) But, my original question is about a concept of whether the utility can be safely expanded, if what has been presented is correct!