9.27 KB, text/html
1.77 KB, text/html
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) BuildID: 2002012403 Composer File Save problem New file create: new file created with 0 Byte length. Existing files are not overwritten with new version. No change to file size or date stamp. Reproducible: Always Steps to Reproduce: Either create a new document or open an exisiting on. Make changes to the document. Attempt to save. Actual Results: New docuement created with 0 byte length. Exiting document unchanged. Expected Results: It should have written the new version of the document to disk.
-->brade Where are you attempting to save? to a network volume or to a local hard drive?
Good question. After a complete un-install and re-install, behaviour is unchanged. Orignal report was for file saves against a Network file share (W2k Adv.server) Behaviour appears to be similar on local file system (Wk2 Pro WS)with one change: New file: file created with 0 byte length. Existing file: Overwritten with a 0 byte length file. Saves attempted from button bar and from file menu. No difference in behavior.
can you save a page in the browser?
I confirmed this behaviour in Windows 98 with the following user-agent string: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.7+) Gecko/20020123 Build ID: 2002012304 This must have been in the tree for at least 2 days, if you notice the date on my build. Is it possible this is a regression? I'll try to check
You've reported this in the past, in bug 121065. Someone please mark this as a duplicate.
Sorry, looking at wrong name field. Different reporters, same owner. Mark this as a dupe, and up the severity of 121065.
Save from Browser seems to be working fine. Further information reguarding opening existing files: Sometimes (~50%) a local or network file opened in the Composer will save updates ok. I haven't been able to determine a pattern for sure, but I have noticed that if it works on a file, then it always works even after you shutdown the mozilla process and restart, and files that it fails on, always fail after restarting.
resolving this as a duplicate; if you see this problem in a newer build (such as one from this week), please comment here or reopen bug. *** This bug has been marked as a duplicate of 119496 ***
Created attachment 67142 [details] HTML file used by SSI directive from another file. With BUILD 2002013003: After opening this file on a local or remote file sysmem (All Windows 2000 platform) and making changes, when I try to save the file, Composers ACTS like it saves (no errors) but the disk file does not change. Something about the contents causes an issue. I have discovered a cumbersome workaround, but it would be nice to use the templates as provided, since they appear to my untrained eye to be ok html code.
Created attachment 67163 [details] File created with Mozilla composer. Can not be saved after aditional edits. Build 2002013003 This file was created, and saved with Mozilla composer. IF I re-open it for editing, make some changes, and attempt to save them, composer silently fails to save the file. Something's still not right with the composer file handler. Please consider changing the status of this bug from Duplicate | Resolved.
Attachment 67163 [details] has link elements with href that looks like "/dir1/file1". Composer doesn't like this because the path does not exist on windows local filesystem. I know this for sure because I have a similar file and when I commented out the link element in it, the file can be saved. Note sure about attachment 67142 [details] but I think similar situation but now in image elements with src attributes pointing to similar kind of paths.