Closed Bug 124093 Opened 23 years ago Closed 23 years ago

Saving of files is broken

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
DEC
OpenVMS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jakobus, Assigned: colin)

Details

PWS 500au, OpenVMS 7.3, Motif 1.2-6, MOZILLA 0.9.8.1 Build 2002020220

Saving a picture shown on a web page results in an error message:
Cannot create file, Directory /iaf021$dka600/ftp/institut.jpg is not writable.

I checked different disks as destination.

I'm the owner of the directories on the disk of course.
I am able to save images with M0.9.8. Can you give me some more details on 
exactly what you are doing?
On page http://defence-data.com/current/page13483.htm I select the picture
http://defence-data.com/storypic/globalhawkshangar.jpg and right click "Save
Image" opens the window "Save Picture" in this window I select my SYS$LOGIN
directory for saving the file. Now opens the window "Error saving ..." with the
message: "Cannot create file. Directory
/iaf021$dka600/iaf/pl/jakobus/globalhawkshanger.jpg is not writable."

I installed MOZILLA under SYSTEM account. SYSTEM has the default protection:
SYSTEM=RWED, OWNER=RWED, GROUP=RE, WORLD=NO ACCESS

I had sometimes trouble with protection, maybe it's the reason again.
That message appears when the "parent" of the filename you want tests false on
isWritable() (see line 318 in filepicker.js).  The fact that the message lists
the filename instead of the dirname is a separate bug, by the way.

The test for isWritable() is in nsLocalFileUnix.cpp:

    *_retval = (access(mPath.get(), W_OK) == 0);

Colin, could this screw up on VMS by any chance?
access(file,W_OK) pretty much works on OpenVMS. Though I'm not saying that we're 
not running into a problem with access()  :-)

Theo, how do you get to SYS$LOGIN? Do you type something into the file picker 
widown, or do you just navigate using the mouse and the ".." button until you 
are at /iaf021$dka600/iaf/pl/jakobus?

Can you also confirm that this problem is NEW to 0.9.8?
Aw crud, I just did a test and access is flunking. I need to poke around and see 
why...
Assignee: law → colin
-> colin
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
is this limited to vms?
Yes, VMS only.

Here's the issue. On VMS, access(file,W_OK) (the check for write access) will 
only succeed on a directory if the caller has write AND DELETE access to the 
directory (this is the way access() works on VMS; nothing I can do about that). 
It is normal practice on VMS for even the owner to write, but not delete, access 
to his/her own directories.

I'm not sure what to do here. I'm not sure what I *can* do. This is the way the 
C RTL works on VMS.
Keywords: qawanted
QA Contact: sairuh → nobody
Colin this didn't happen and I started with version M10 in the last century ;)

I navigate to the directory by using "..." only.
/iaf021$dka600/iaf/pl/jakobus is my login directory and the last change was in
the last century (I like this joke) :))

Of course I've write and delete rights on my login directory so your argument
with access(file,W_OK) doesn't fit to this bug. If I use MOZILLA 0.9.7 I'm able
to save the picture so what was changed in the code?


Colin,

I checked this under SYSTEM account and again I got the error message :(

If it doesn't work under SYSTEM account with all privileges then it's not an
access problem.

I'm worried that you are able to save, so I guess it's an installation problem.
Since I'm testing on my personal workstation I'm able to reboot without harming
anybody. So I'll reboot, according to the law: if there is no idea reboot !!!
You have write and delete access on your login directory? Are you SURE? Please 
check again and post the output of 

$ dir /sec iaf021$dka600:[iaf.pl]jakobus.dir

Thanks.
Theo, I DO see the problem if I run from an account which does not have both 
write AND DELETE access to the directory.
I can confirm that this is new to 0.9.8 and occurs on OpenVMS Alpha 7.2-1 and
7.3.  I can also confirm that the symptom goes away when I give myself delete
access to the directory where I am trying to save.  Is the access check new to
0.9.8?  A more robust access check for VMS could probably be done by calling the
native services sys$create_user_profile followed by sys$check_access, though
that would require converting filenames to native format for the test.  If the
access check was already present in 0.9.7, then something about it appears to
have changed and that change broke it on VMS.
The access check is new to 0.9.8. Its the access routine in the CRTL that is 
requiring DELETE access for a write check. This will be fixed in a future 
release of the CRTL I am told.
I have a workaround applied to the VMS jackets that will cause an access write
check to always return true if VMS_ACCESS_FIX_WOK is defined. This allows the
save feature to work again but has some other undesirable side effects. Most
noticable is that in 0.9.8 much of error checking when a page is saved is done
BEFORE the file is created, and little error checking is done on the open/creat
operation itself. Consequently with the above hack we don't detect when a file
really can't be written. I believe that 0.9.9 has improved the error checking in
this area (bug 27609) and I hope that in 0.9.9, even with this hacky workaround,
Mozilla will correctly report an error when it can't save a file.

Theo, if you want to try the modified jacket routine, let me know. I think we'll
have to ship it in 0.9.9 just to allow people to save files.
Colin,
$ dir /sec iaf021$dka600:[iaf.pl]jakobus.dir showed (RWE,RWE,RE,E) after
changing to RWED for the owner file saving works, thanks for your help!

I would like to test the modified jacket routine send it with an e-mail.

In the window "Save Picture" going up by using "..." resolves the logical
PL_DISK and ends at device level which is here iaf021$dka600. Is there any
chance to offer logical assignments only? So any user is able to select between
defined logicals.

Theo, I've sent you the hacked up jacket routine to play with.

For the PL_DISK logical question, I'm not quite sure what you're asking for. If 
you're getting an error when you ".." up to /PL_DISK then I'm 99% sure its 
(another) problem in the CRTL's access routine. Several problems in this area 
are getting fixed in the next CRTL ECO. What exactly is your PL_DISK defined as?
I'm closing this bug report because the Mozilla code really is behaving the way
it should. Its a feature of the C RTL that an access(dir,W_OK) check will only
succeed if the caller has BOTH write and delete access to the directory (for
non-VMS people reading this OpenVMS has 4 protection fields, read, write,
execute, and delete, instead of the usual 3 that UNIX has).

A future C RTL ECO will address this issue.

However, since so many VMS users are going to get bitten by this I've put some
additional code into the VMS jackets to work around this problem. This will be
present in the M0.9.9 release.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Colin under OpenVMS is the logical device PL_DISK defined as:
DEFINE/SYS/EXE PL_DISK IAF021$DKA600:[IAF.PL.] /TRANSLATION=(CONCELEAD,TERMINAL)
We use for applications and projects logical devices, the user doesn't "see" the
real disk. This enables us to control protection in an efficient way.
The action "Save picture" or "Save file" starts with /pl_disk/jakobus which
represents my login directory. Using "..." I get /pl_disk and then / and in the
file window are the devices shown. If I select a device like iaf021$dka600 the
directory is shown as //iaf021$dka600 which is bug 84760.
If the protection of iaf021$dka600:[000000]000000.DIR is set to W:E, which is
our standard, the "Save As" hangs after pushing "..." at level /pl_disk. I would
like to get /pl_disk as top level offered if I push "..." again and again.
 
From "/" you will always see the list of available devices, regardless of how 
you got there. "show device d" won't show PL_DISK as a device, and for the same 
reason neither will Mozilla.

But in the "file name" field of the save dialog you can enter "/PL_DISK" and hit 
return, and this should position you to where you want to be (note that because 
of a CRTL issue you might have to enter /PL_DISK/000000).
Keywords: qawanted
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.