A SAVE-session to directory option added for PUPs [REOPENED]

[jamesbond]

gcmartin, most of your previous post (just above mine) doesn't make sense.

But you have got one point right. That is, configured correctly, NTFS can indeed be used for "savedir". I've just tested and implemented that in Fatdog.

Whether it is wise to do so is another matter - a discussion that does not belong to this thread (and as a disclosure - my position is more towards "unwise").

For others: the key to be use ntfs as savedir is that when mounting it, you need to:
a) use a recent enough version of ntfs-3g; and
b) specify "-o permissions" so that POSIX permissions are correctly stored.

[rcrsn51]

(and as a disclosure - my position is more towards "unwise").

Agreed. On all my machines, I put a wrapper around ntfs-3g that only runs it with "-o ro". So there is no chance of corrupting a Windows partition.

[gcmartin]

Thanks for your comments and your insights to further explain findings in the community.

OK, then what is being suggested is that the "unwise" positions is that placing (and use) a save-session on NTFS runs a potential of corrupting the existing clean NTFS partition. And extending that, there is a potential that the save-session could be written to an already corrupted partition. This is similar in scope to what "could" occur with a Linux partition. Yes, I too, have had Linux partition corruptions.

But, as has been shown by the comments and other posts in the net and forum, current Linux NTFS support WORKS! ... in such a way that it "could" be a usable for PUP's save-session folders.

If there is a need for an explanation of where I see potential, its the age-old delivery of MS running on PCs that come from the manufacturers where in many-most cases, the PCs deliver with NTFS. When we help users who may want to see/test/use a PUP distro, the need to save the user's work is an issue. The ability for the shutdown to offer the folder option provides some benefit in safe savings across reboots. This would negate simple user understandings and allows them to "see" Linux, not as some magic use of files (like .2fs/.3fs/.4fs), but rather a folder, like any other, the users normally have used in Windows in their lifetime.

Further, we reduce the need "educate" them on a new world of filesystems, when they only want to know if it works and can they run their applications in an environment the maps to what they have come to expect.

It makes our job little easier and it make for a comfortable user start.

Most of us have, "no problems", But new users are coming to us with years of Windows background knowledge and most recently with "TOUCH" devices knowledge. When we show them things consistent with their understanding "everyone wins", IMHO.

In summary, the "real" answer is YES, a save-session folder should be expected to work, as well, on a NTFS partition; same as it does on a Linux partition. An folder discovery on reboot would work the same, no matter the partition type.

[rcrsn51]

In summary, the "real" answer is YES, a save-session folder should be expected to work, as well, on a NTFS partition; same as it does on a Linux partition. An folder discovery on reboot would work the same, no matter the partition type.

Jamesbond did not mention a key factor in his testing. Did he use an NTFS data partition or an NTFS Windows partition? It makes a huge difference.

Any suggestion that Puppy should start putting save folders into Windows is wildly premature.

[gcmartin]

I think we are talking about filesystems and whether a folder put there by Linux which contains links+data used by Puppy Linux, will survive over reboots.

In your reference are you talking about the same thing. There is no mention by me to advocate Windows. I think everyone understands that.

But, if there is a difference, as you are stating, please reply. We all benefit by putting "all the cards on the table".

Glad you brought that to our attention, but, it needs clarity. Thanks in advance for any reply from you or others to help our understanding.

[rcrsn51]

There is no mention by me to advocate Windows.

But new users are coming to us with years of Windows background knowledge and most recently with "TOUCH" devices knowledge. When we show them things consistent with their understanding "everyone wins", IMHO.

How else would a newcomer be putting a save folder in an NTFS partition if not in his existing Windows partition?

[tlchost]

I run all my puppies on a fat32 usb drive. Am I correct in thinking the savedirectory mode can not be used with fat32?

If incorrect, how can I go about using the savedirectory in fat32?

thanks

[rcrsn51]

Am I correct in thinking the savedirectory mode can not be used with fat32?

Yes. But I am finding that formatting a flash drive as ext4 and using a save directory will get you much better performance.

YMMV.

[Ted Dog]

Can't answer for JB but will
I used fatdog64 in a windows8.1 DATA ntfs and only had minor problems nothing risking data just pop some file parm errors on some tricky files in etc. In this case it was a harddrive redone with old school MBR type which I boo ted in EFI mode for Fatdog64/all other linux but AprilQ (MBR)

Hay this is his topic let him put whatever is relevant to him,

[jamesbond]

Jamesbond did not mention a key factor in his testing. Did he use an NTFS data partition or an NTFS Windows partition? It makes a huge difference.

I tested with qemu in a virtual partition I made with mkntfs. That would classify it as "NTFS data partition". Note that I didn't test whether Windows can access that NTFS before or after; I didn't test co-existence with Windows. I only tested that I can persist the session successfully and the filesystem didn't generate any errors that ntfs-3g could detect.

Any suggestion that Puppy should start putting save folders into Windows is wildly premature.

Agreed. Apart from more testing needed, there are other potential issues as well. I can see the benefits, yes, but to be fair we must acknowledge that there will be issues too.

[jamesbond]

I just remember to add another reason *against* having ntfs savedir in puppy: has puppy solved the problem of unclean shutdown on ntfs? I know that puppy has solved it for linux filesystems; and even if it doesn't, "pfix=fsck" will usually fix it at boot.

The same can't be said for ntfs. I don't think puppy will attempt to do "ntfsfix" on ntfs if you give pfix=fsck; and even if it did, ntfsfix can only fix minor problems. Over time the problems caused by unclean shutdown will grow to the point that you start losing data and/or running Windows chkdsk is necessary.

Now one of you might say, isn't this the same situation when one uses savefile in ntfs? It is not the same. For one thing, savefile is created/allocated only once; after that all saves only happen inside this pre-allocated extents - the real ntfs filesystem modification happens very rarely if not at all (e.g. timestamp modifications, etc).

Running savedir in ntfs however means that the ntfs filesystem will be constantly modified and updated; thus higher chance of corruption at every shutdown; and the small corruption that happens now and then will slowly grow until you have serious problems; unless you reboots into Windows now and then to chkdsk the disk.

This is not a problem on Fatdog because Fatdog can unmount ntfs cleanly during shutdown. But as far as I remember puppy can't do clean shutdown other than on linux filesystem. I hope I am mistaken.

[rcrsn51]

I can see the benefits

I can see no benefit at all. The standard Linux mantra is to criticize Windows for being fragile. So why would Puppy jeopardize a newcomer's Windows setup by dumping even more content into his NTFS partition(s). This becomes especially dangerous if it happens to be a recovery partition, which are designed to be untouched.

The average Windows user can't even spell NTFS, let alone understand the implications of installing Puppy there.

[gcmartin]

Thanks @Rcrsn51. I can see that you would feel the user to be very naive. Your reasoning draws attention to the now-normal HDD setups that come with every preloaded system. For Windows PC, this layout is pretty much standardized.

But, we are not mandating anything! I was considering this based on 2 things

• Choice of a save-session folder OR file on an existing NTFS partition in one's system
• Choice where he/she is dealing with a folder/directory where EVERY Windows/Apple users understands. (If I mention folder/directory to any one of them, they know what I am talking about. If I mention *.2fs or similar we all know the looks we get.)
  
  We don't mandate anything today/tomorrow. We offer reasonable selection choices to the user at shutdown time.

Technically, though, we are addressing capability of information survival across boots via save sessions on a filesystem which appears to be safe for such. This is true no matter who the user is or his background.

I can see that someone would want to NOT allow that technical ability to anyone, but, there is an advantage to that ability. Especially in light that we are doing so with a "*.2fs/3fs/4fs/..." on today's NTFS filesystems. If we step back and look,we might see that regardless, either, save-session folder or file, both survive with their contents intact over reboots.

Just thoughts to gain clarity on the subject.

If for no other reason, this topic brings additional awareness to planners, devs, and Puppy Linux users for maintaining and using information in a safe manner. Until this discussion, the "survival" knowledge was based upon our older understandings as well as a requirement for loop device needs for Puppy information. Thus, up until this topic surface, our views were not centered with many feelings based upon ideas of times gone by versus what we know, today. Further, this ONLY about technical truths.

[jamesbond]

I want to avoid the discussion on the (de)merits of savedir on ntfs here, because I thought this is mainly about the technical discussion about "can/cannot" and "how to do it" rather than "should/shouldn't". But apparently it is unavoidable. And I'm a little bored at the moment so here we go

---

I can see no benefit at all.

I thought the benefit is obvious: it is that a user can enjoy the benefits of a savefolder (no size limit - the partition size is your limit) without the need to create a dedicated Linux partition - a daunting task for a typical user (steps: boot Windows, go to Disk Manager, Defrag, Shrink partition, wait for 3 hours, boot to puppy, use gparted to create Linux partition, get confused over ext2/3/4, especially problematic on MBR disks when all primary partitions are occupied, etc).

Is it worth the risk? Is using savefile so bad that one has to go with savedir?
My answer: Decide for yourself.
Risk #1: http://murga-linux.com/puppy/viewtopic. ... 060#867060
Risk #2: quoted from rcrsn51 above:

So why would Puppy jeopardize a newcomer's Windows setup by dumping even more content into his NTFS partition(s). This becomes especially dangerous if it happens to be a recovery partition, which are designed to be untouched.

Fully agree. This is a very real mistake waiting to happen.

I can see that you would feel the user to be very naive. Your reasoning draws attention to the now-normal HDD setups that come with every preloaded system. For Windows PC, this layout is pretty much standardized.

Unless your users are specialised IT people (or computer hobbyist), they are most likely do not know what those "now-normal HDD setups" are. Even if your claim that "this layout is pretty much standardized" is true (which is not - but lets pretend it is) - your typical user probably don't know much what each partitions they see in their layouts are for. For example, my UEFI laptop comes with six (6) factory-prepared partitions. Can you figure out what each are for, and which one is safe for me to use?

This is also a problem for those using savefile; but the risk is much smaller compared to using savedir which involves a lot more filesystem operations than a savefile.

But, we are not mandating anything!

Ah but you do. You mandate that puppy developers include this "choice" despite the risks. Please don't quote Fatdog providing this support as an example for others to follow - for one, the support I added isn't public yet and probably won't be for weeks or month to come. For two, Fatdog can cleanly umount ntfs at shutdown - so the risk is a tad smaller - but can other puppies do that?

Technically, though, we are addressing capability of information survival across boots via save sessions on a filesystem which appears to be safe for such.

But as I and rcsn51 said above - it is *NOT* safe.

I can see that someone would want to NOT allow that technical ability to anyone,

You must be new here. One thing that I learnt from this forum is that if a feature is generally useful and not risky for many people; sooner or later it will get implemented. I have not seen a single someone that "would want to NOT allow that technical ability to anyone" ... that's quite an accusation (especially if you refer to rcrsn51 whose public contributions are all over this forum: from PeasyApps suite to many other nifty little tools, specialising on making difficult things easy for newbies).

but, there is an advantage to that ability.

Finally we can agree on something. But the question is - is the advantage worth the risk?

both survive with their contents intact over reboots.

Yeah, but which one will survive longer?

If for no other reason, this topic brings additional awareness to planners, devs, and Puppy Linux users for maintaining and using information in a safe manner. Until this discussion, the "survival" knowledge was based upon our older understandings as well as a requirement for loop device needs for Puppy information.

OK, the second thing I can agree with you. I'd even give you the credit for this. Your original post to this topic did bring awareness of this persistence model to the larger Puppy community which later got incorporated to later Puppies; although I personally implemented it in Fatdog a year before your post and Slax (where we took the idea from) implemented in even before that.

Further, this ONLY about technical truths.

Yeah right

EDITED for clarity:
In the end, I'm curious - you, the multisession-DVD champion who would *never* use savefile because you don't want anything to touch your precious harddisk (for fear of corruption, data loss, unbootable Windows, perhaps?), now advertises a method (=savedir on ntfs) that is very prone to making such fear turns into reality on regular basis? No answer needed - this is just a rhetorical question

I'll take Ted Dog's advice:

Hay this is his topic let him put whatever is relevant to him

so I'm outta here

[Ted Dog]

Wouldn't answer for gcmartin, but dvd multisession has not be as bullet proof as it has been, and its never been to my ideal use yet. EVEN I with my history of support I know WHEN it doesn't make sense. Its not an either or issue or single method is best.
I think savefolder offers the best environment for most situations, but still would prefer an archive type system like multisession on optical provide. I have never met data I did not like I am sure I am a data horder, may need a 12 step program to use computers like other who use a delete key.
SO WHERE EVER ITS IDEA CAME, glad someone took it out of hidding, pointing out you had it working years ago, Ahhhhhhh, dude you are true to your spy name, guess us users didn't need to know about that!
I HAD NO INSIDER KNOWLEDGE, I did it by accident! Wonder what else is hidden jems exists, that will now cause me too spend time snooping around and not finding fixes..

[Jasper]

Hi Ted Dog,
You wrote:

Code: Select all

dvd multisession has not be as bullet proof as it has been

That statement is poorly worded and vague; please expand it and explain what you mean.

You also wrote:

Code: Select all

Hay this is his topic let him put whatever is relevant to him

Who, except a moderator (or such as an assassin if his infamy is sufficient- else a muderer), could stop him.

My regards

[Ted Dog]

Thanks for pointing that confusion Jasper..

The DVD multisession is a method and supporting code to add changes from running the OS back to the optical drive. There really IS NOT a lack of support or reduction of support but a side effect of something else that is causing the lost of session data to be made written back to optical drive.
Second the other statement was the general trend to reduce the focus of topics, of which posters seem to single out one active poster for judgment. There are not many active poster left on this board, we should treat each other like the others ideas are golden and give a pass for unexplainable positions, that may only need to be expanded or explained BETTER.
As our interchange pointed out not everything that seems clear to poster is clear to reader.

[gcmartin]

This is also a problem for those using savefile; but the risk is much smaller compared to using savedir which involves a lot more filesystem operations than a savefile.

Cannot agree!

On a safe to use Linux filesystem, I do not see a greater risk. One writes directly to folder, while other writes to a file which looks like a folder which then must be mounted on a loop device to read.

I dont believe you can extrapolate one being the lessor of the other.

And on the mandating, I think your depiction is not accurate, at least I dont see it that way.

Lastly, trusting users (or anyone) to place save-sessions isn't any different than it is today. The current utility presents a bunch of options. I am just thinking that a safe option, as well, is any system which also has NTFS being treated similar to what we do for ext2/ext3/ext4s, today; now that we know placement on NTFS is technically safe. No one is running away from presenting options to a user, IMHO.

I step back, as well, as this topic stands on its own merit(s)/demerits for understanding the potential use provided from another safe filesystem that Linux understands very well.

Hope this is both accurate and clear.

[rcrsn51]

...another safe filesystem that Linux understands very well.

Really. Then explain all the reports from people who cannot mount their NTFS internal hard drive or external USB drive as writable because ntfs-3g somehow sees it as dirty.

The standard advice is always "run a filesystem repair from Windows". Not very Linux-friendly.

[gcmartin]

I think you are suggesting that Linux has done that. You may be correct. Windows use without Linux on the PC has had these kinds of problems. Further, we have had similar problems with filesystem corruptions on ext2/ext3/est4s as well (I, for one, had this occur on 2 occasions since I became a PUP user). This did not deter use. I, like yourself, understand that anyone can get hit with filesystem corruptions for any of a miriad of reasons.

I do agree that corruptions have been and still is a very real fact of life on any filesystem.

I have not had that problem in use from Linux. Have you? What did you do to correct? But I am curious if you had: how did you discover that Linux caused it (this insight would be useful)?