Save File Issues

[jimwg]

Greetings:

I couldn't reply to the original topic and response by Fanthom so I'm transferring them here:

Postby fanthom » 25 Feb 2014, 03:48
how does one know whether it's large enough or too excessively large just to save what you need?
depends what you use Porteus for (downloading many youtube videos?). system itself should take about 50MB but mind that firefox files/kde thumbnail caches/etc will grow quickly so i would go with 1GB on start.

Can you "undersize" a savefile.dat and unwittingly omit files you hope to save?
save.dat manager offers an option to resize container so it should be possible to make it smaller. run 'df -h' and check how much free space aufs has. if it's few hundreds MB then you could make it smaller but mind above - caches will be growing so probably would be wise to disable them. go to /mnt/live/memory/changes and identify which apps produces biggest files -> search on google how to disable this.

On log-off or mid-session we wish to simultaneously create or update a savefile.dat file as a off HD backup while also still having the identical date saved as "normal" Porteus Changes files. Is there any script that permits this?
nothing i know about

Just a issue for the clarity of newbies and Porteus beginners, is it possible for the .dat file saver to do a tally sum of all the files that would fill one's (minimum-sized) .dat file? It seems that one could only size a .dat file for one's particular set-up now by sheer guesswork, which invites gross overestimation or undersized .dat files that'll leave out files meant to save. It'd help demystify and de-geek the use of .dat files and make it more friendly for them to use.

Simultaneous normal and .dat savefiles saving is a top wish lister!

Thanks!

Jim In NYC

[fanthom]

is it possible for the .dat file saver to do a tally sum of all the files that would fill one's (minimum-sized) .dat file?
save.dat manager creates an empty save.dat and do not copy current session to it (as session is not over) but could display an info about current size of changes.
there is one risk: session is very small at the beginning (4.2 MB for kde4 desktop after start) but can grow fast so this info would be misleading especially to the beginners who would create too small containers -> troubles in the future.

It seems that one could only size a .dat file for one's particular set-up now by sheer guesswork,
correct.
please boot in always fresh -> setup system as you like -> run 'du -h /mnt/live/memory/changes | tail -n1' to get estimate size of the changes -> create save.dat with that size + 50MB -> reboot with changes= cheatcode pointing to save.dat -> setup system as you like again -> add 'changes-ro' cheatcode (porteus-3.0 only) to freeze changes and done.

[jimwg]

is it possible for the .dat file saver to do a tally sum of all the files that would fill one's (minimum-sized) .dat file?
save.dat manager creates an empty save.dat and do not copy current session to it (as session is not over) but could display an info about current size of changes.
there is one risk: session is very small at the beginning (4.2 MB for kde4 desktop after start) but can grow fast so this info would be misleading especially to the beginners who would create too small containers -> troubles in the future.

It seems that one could only size a .dat file for one's particular set-up now by sheer guesswork,
correct.
please boot in always fresh -> setup system as you like -> run 'du -h /mnt/live/memory/changes | tail -n1' to get estimate size of the changes -> create save.dat with that size + 50MB -> reboot with changes= cheatcode pointing to save.dat -> setup system as you like again -> add 'changes-ro' cheatcode (porteus-3.0 only) to freeze changes and done.

Got it.

Fanthom, you're so astute and resourceful in answer that I HATE to offer this newbie/beginner-based opinion, but PLEASE don't ask one to do what you well-described here. Porteus will lose newbie try-outs and OS tasters faster than roaches scurrying away from a bright light to demand a relatively techie solution like that. Please, it behooves Porteus' user-friendly repute to try to automate or menu/macro-simplify solutions to issues as these! Maybe you suggested one possible solution yourself; why can't Porteus auto execute a script at log-off that does just that; (" run 'du -h /mnt/live/memory/changes | tail -n1' to get estimate size of the changes -> create save.dat with that size + 50MB -> reboot with changes= cheatcode pointing to save.dat -> setup system as you like again -> add 'changes-ro' cheatcode (porteus-3.0 only) to freeze changes and done") and takes the result to create an aptly sized .dat file to stuff the changes into? Also -- and we looked over the excellent Porteus tutorial for it -- but there's no hint informing that save.dat manager _doesn't_ save your current session during its creation but just creates an "empty box". Most beginners would logically assume it saved current session upon creation. I sure did and I've been months into Porteus! This misunderstanding could cost Porteus a lot of surprised and disaffected dabblers and newbies.

I'll gladly beta-test anything you guys whip up!

Just wish to see Porteus top Puppy and Mint.
Jim in NYC

[Ed_P]

@jimwg

My save.dat file is 128MB. It fits my needs in that I download and save very little with Porteus. I config FF to delete history when I log off it. And I run a script to run the logrotate function prior to shutting down Porteus. I periodically check my save.dat usage by booting Porteus in Fresh mode and following the commands posted here: http://forum.porteus.org/viewtopic.php? ... =15#p13272

My usage is usually about 75%.

For files I wish to save manually rather than using the save.dat function I save them directly to my USB drive.

Whether 128MB and how I use Porteus will work for you I have no idea because I don't know how you are using Porteus. But maybe what I do will give you some ideas on how to manage what you do.

[jimwg]

@jimwg

My save.dat file is 128MB. It fits my needs in that I download and save very little with Porteus. I config FF to delete history when I log off it. And I run a script to run the logrotate function prior to shutting down Porteus. I periodically check my save.dat usage by booting Porteus in Fresh mode and following the commands posted here: http://forum.porteus.org/viewtopic.php? ... =15#p13272

My usage is usually about 75%.

For files I wish to save manually rather than using the save.dat function I save them directly to my USB drive.

Whether 128MB and how I use Porteus will work for you I have no idea because I don't know how you are using Porteus. But maybe what I do will give you some ideas on how to manage what you do.

Thanks for the reply.

Please understand that I'm taking it from the perspective of a newbie not a techie, so it's not so much as how I would use Porteus but tripping across desires and wants that a news-spreading beginner would have. I always want a techie to have every option to tailor what they want, I'm just saying also make a ease-of-use "low road" option for the newbie to help popularize the OS. First request they have is ease of use which Porteus does well, but second is the relief that your work is being easily and safely saved. To me a newbie should never see a command line or dabble with scripts to do anything; it makes most nervous and feel they have to be a geek to reassuredly "get it right." That was the Mac's shining achievement over MSDOS, and something the Puppy and Mint folks had to learn to gather fans. I think Clonezilla offers the best example of dealing with techie issues as you cite for newbies; a menu system asking the user what you want done: "Do you wish to save in the following available drives?" "I auto-detect that this is a FAT drive. Shall I save your work in a safe.date file or a plain file?" "Would you like a minimum sized save.dat file?" "I have auto-checked the save.dat on drive X and it is well/needs updating. Can I?" and etc. Maybe I'm asking for a macro-creator type "cheat sheet/script generator" or such to do the job to get around touching command-lines.

Again I'm not a programmer, I'm just taking the view of a surfer who came upon Porteus and is trying it out to see how powerful yet easy it is to use.

Jim in NYC

[donald]

@ jimwg
I understand your point of view.
Here is another one:
As Windows belongs to a Windows Filesystem, Linux belongs to a Linux Filesystem.
And if you do it that way, you will never have to worry about a save.dat-file
or how to save changes. 8)

[Ed_P]

I think Clonezilla offers the best example of dealing with techie issues as you cite for newbies; a menu system asking the user what you want done: "Do you wish to save in the following available drives?" "I auto-detect that this is a FAT drive. Shall I save your work in a safe.date file or a plain file?" "Would you like a minimum sized save.dat file?" "I have auto-checked the save.dat on drive X and it is well/needs updating. Can I?" and etc.

IMO A true non-tech newbie would have no idea how to answer a question about a FAT drive or a safe.data / plain file question or what size the save.dat should be. I'm thinking a non-tech newbie as being a school kid or someone's grandmother. Non-techs want a system they turn on and use; read their email, surf the web, play games, do homework. A similar concept to driving a car.

As Windows belongs to a Windows Filesystem, Linux belongs to a Linux Filesystem.
And if you do it that way, you will never have to worry about a save.dat-file
or how to save changes. 8)

True enough but USB drives come formatted as FAT. To switch to a Linux Filesystem you must be running a Linux system, and if you are just starting ....

[Ed_P]

So driving a car falls under kiddie cake? That example lacks a lot of meaningful logic.

Turn key & start car, shift gear from Park to Drive, press the gas pedal, aim car with the steering wheel. Yeah, pretty straight forward. No concerns about changing the oil, rotating the tires, anti-freeze, etc. Same as someone new to pcs, or tablets, turn on machine, click on desired icon. No concerns about the size of the page/swap file, or even an AV app.

I used to carry a full system on a simple floppy; long before fancy USB gimmicks,

Me too. And I'm talking both the ones that were large and bendable and the smaller plastic cased ones.

[donald]

.....but if you want to drive on the roads, you have to learn the rules to get a License......

[brokenman]

Anything can be scripted or automated. But the question is ... should it? Including the savefile in Porteus is not an option since a 128Mb savedat file is almost half the size of the entire ISO. We are still aiming at falling into the lightweight category of Porteus linux. The 'Port' in porteus comes from portable and when it first started this also included the option for recordable and non writable media such as CD or USB (locked). We must keep this in mind when deciding whether we can automate something. So that leaves creating the save file ''on the fly'.

One of things I loathe about windows is when I turn my system off and it says "Don't turn off your system ... update 3/327". Porteus for me shuts down in less than 3 seconds. No questions. We could delay this with questions such as "Have you saved your report?", "Do you want to create a container to save it in?", "What size?", "Where should I save that?", "What format?" and then spend the time creating the container if all answers are answered correctly. This is also going to confuse a new comer. I would much prefer to write a windows installer for Porteus that creates an ext4 partition and buries save containers for good.

So, nothing is impossible to script by any means but I agree with what someone said above ... we need to find a way to use a native linux filesystem for a linux operating system. This does away with all the problems we face here. If the problem is that manufacturers still ship devices with an antique file systems then that is the problem we need to address. Altering the filesystem and installing Porteus.

For me a save file is like tightening a screw with a pair of scissors. It may work, and you may eventually secure whatever you are wanting to secure, but isn't it better to use the right tool?

[Ed_P]

Anything can be scripted or automated.

Spoken like a true tech.

But the question is ... should it?

A valid question. Two other valid questions in a business environment are, when do you want it and how much are you willing to spend on it.

Including the savefile in Porteus is not an option since a 128Mb savedat file is almost half the size of the entire ISO.

Totally agree but including the option to automatically create one depending on the file system being used should be possible for an install. The option could have a menu providing the user two possibilities, default and custom. The default would choose the location, format and size. The custom would let the user choose those values.

But that scenario does not totally eliminate the save.dat question as it only applies to installs and not all of us users install Porteus. Some of us run it along with other OSs on the same flash drive or even the same hard drive in it's ISO format.

One of things I loathe about windows is when I turn my system off and it says "Don't turn off your system ... update 3/327".

It only happens once a month.

Porteus for me shuts down in less than 3 seconds. No questions.

When I shut it down I get a prompt indicating I will loose my work and do I want to continue.

We could delay this with questions such as "Have you saved your report?", "Do you want to create a container to save it in?", "What size?", "Where should I save that?", "What format?" and then spend the time creating the container if all answers are answered correctly. This is also going to confuse a new comer.

But this would be a one time thing. Once created future shutdowns would use it automatically. And if a menu option is used with a default / custom choice it should not overly confuse a new comer.

If the problem is that manufacturers still ship devices with an antique file systems then that is the problem we need to address.

They choose the file system that is compatible with the most operating systems and devices. And ext4 and NTFS and HPFS aren't it.

For me a save file is like tightening a screw with a pair of scissors. It may work, and you may eventually secure whatever you are wanting to secure, but isn't it better to use the right tool?

An interesting example, but reducing Porteus's flexibility in working environments would reduce new users trying it. I for one would not do it.

Either one wants a lightweight portable system, which would obviously come with a bagful of limitations, compared to a full install, or the latter, in which case none of this saving what, how, and where issue would even exist.

A lightweight portable system like that has been around for years, it is called DOS. And you see how popular it is now days.

[brokenman]

Two other valid questions in a business environment are, when do you want it and how much are you willing to spend on it.

Very valid questions in a business environment. We need the equivalent for a hobby environment where the overheads are mainly time (lots of it) and the return is peanuts.

The default would choose the location, format and size. The custom would let the user choose those values.

Fanthom did write an automated savedat creator which kicked in during boot when it sensed a FAT partition. The consensus was that stopping the boot process leaving users looking at a text based screen was too daunting. Using a GUI upon exit (when no changes= is found and on a FAT partition) is probably an option.

Some of us run it along with other OSs on the same flash drive or even the same hard drive in it's ISO format.

Good point. We export the operating as an ISO so it is fair to assume that many people will run it as such. Remember though that this means there is no 'default' option for creating a savefile since the destination needs to be physical and the system can't guess/assume that.

They choose the file system that is compatible with the most operating systems and devices. And ext4 and NTFS and HPFS aren't it.

http://en.wikipedia.org/wiki/Universal_ ... ng_systems
http://duncanlock.net/blog/2013/05/13/u ... sh-drives/

reducing Porteus's flexibility in working environments would reduce new users trying it

My aim would not be to reduce anything, but change the handling. If a savedat file didn't exist (but your work got saved anyway) then you wouldn't know the difference! The base of the problem is filesystem. FAT is antique, limited and obsolete. I can't even copy my 4Gb family Christmas video onto it! It needs a big FAT coffin.

A lightweight portable system like that has been around for years, it is called DOS. And you see how popular it is now days.

Hey, there the same guys that invented FAT ... in 1976!!

[dustbunnies]

Having chosen xfs format for my savefile.dat container (b/c ext2 isn't, I've just discovered a "gotcha":
cannot SHRINK the size of an existing xfs filesystem
http://xfs.org/index.php/XFS_FAQ#Q:_Is_ ... smaller.3F
Choosing xfs for savefile.dat and specifying an overly large size can be problematic when you later want to use copy2ram boot option

BTW, I've searched the forum and didn't find an explanation/rationale: Why is the non-journaling ext2 fs not offered as an option ?

[fanthom]

Choosing xfs for savefile.dat and specifying an overly large size can be problematic when you later want to use copy2ram boot option
dont understand what you mean but will try to answer:
copy2ram makes no difference from save.dat point of view. modules are loaded from tmpfs and not from booting media - both takes no effect on changes.

Why is the non-journaling ext2 fs not offered as an option ?
good question - probably because nobody asked for it so far i'm sure brokenman will address this request in next release.
thanks

[francois]

@ jimwg
I understand your point of view.
Here is another one:
As Windows belongs to a Windows Filesystem, Linux belongs to a Linux Filesystem.
And if you do it that way, you will never have to worry about a save.dat-file
or how to save changes. 8)

Thus the solution would be to stop using these save.dat containers. Have a usb key partitioned in linux for most part of the key and add a second partition in fat so the data is available from the MS environment.

This partitioning of the usb could be friendly automated isn't it?

When you have such a mostly unix-enough fat usb-key, what are the advantages of keeping these save.dat containers except for having an additional alternative to install porteus. What are the pros and cons of using these containers? Why would you reccomend it? They create more problems than they solve.