Re: [Freedos-devel] [freedos-devel] Working on FreeDOS Edlin 2.22

2023-01-04 Thread Ralf Quint

On 1/3/2023 4:33 PM, Jim Hall wrote:

On Sun, Jan 1, 2023 at 7:47 PM Gregory Pietsch  wrote:

...

Your opinion?

Here are my thoughts:

I think if I had marked a file as read-only (such as a
"known good" copy of a file I was working on) I would be
really unhappy if Edlin overwrote it without telling me it
was going to do that. So my recommendation is to not change
the file permission without asking the user. It might be
safer instead to just print a message like "Backup file
is read only - cannot save a backup copy of this file"
so the user knows what's going on.

I would agree with that.
Beside giving that warning about the backup file being read-only (which 
has a .bak file extension, right?), I would suggest maybe to save it 
under a different file extension, instead .bak, using .bk or .bk2.
If that file also exists (and could possibly be read-only) well, tough 
nuts. Give another warning message and/or offer the option to play 
thermonuclear war... 


Ralf 


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] [freedos-devel] Working on FreeDOS Edlin 2.22

2023-01-03 Thread Jim Hall
On Sun, Jan 1, 2023 at 7:47 PM Gregory Pietsch  wrote:
> I'm working on version 2.22 of FreeDOS Edlin, the only editor that
> matters. Right now I'm messing with the code that creates backup files.
>
> Historically/Hysterically, if the backup file existed and was read-only,
> a warning was dispatched and the backup was not created. I was wondering
> for FreeDOS if I should just call stat() to discover if the backup file
> is read-only (once I have determined that it exists) or call access()
> with R_OK as the second parameter.
>
> Boy, following incomplete documentation is sure fun because you can
> embellish what is there and say you followed the specs. I say that
> sarcastically.
>
> Your opinion?

Here are my thoughts:

I think if I had marked a file as read-only (such as a
"known good" copy of a file I was working on) I would be
really unhappy if Edlin overwrote it without telling me it
was going to do that. So my recommendation is to not change
the file permission without asking the user. It might be
safer instead to just print a message like "Backup file
is read only - cannot save a backup copy of this file"
so the user knows what's going on.

That made me look at what happens with Edlin if I try to
edit a read-only file. So I created a test file with one
line, set "ATTRIB +R" to make it read-only, then edited
it again. And I was able to save my file. I didn't get a
warning that the file I was trying to write was already
read-only. That doesn't seem like correct behavior. (I also
tried Edlin on Linux: I opened then modified a read-only
file. I was able to save it, and my previously-read-only
file now has rw permissions.)

To compare:

If I try to open then save a read-only file with EDIT,
I get an error: "Could not save __, try again?"

On Linux, if I try to open then save a read-only file with
ed(1), I get an error: "__: Permission denied"

Both of those seem like better behavior when trying to
edit a read-only file.

Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel