User-Agent: Mozilla/5.0 (X11; U; OpenVMS AlphaStation_DS10_617_MHz; en-US; rv:1.4) Gecko/20030710 SWB/V1.4 (HP) Build Identifier: Mozilla/5.0 (X11; U; OpenVMS AlphaStation_DS10_617_MHz; en-US; rv:1.4) Gecko/20030710 SWB/V1.4 (HP) After generating several levels of subfolders, tried to rename some of the subfolders. Most were successful but there were some that resulted in the Alert: "The folder could not be renamed. Perhaps the folder is being reparsed, or the new name is not a valid folder name." Reproducible: Always Steps to Reproduce: 1.generate 5 or 6 layers of subfolders. 2.Randomly rename the subfolders. Actual Results: One or more subfolders could not be renamed Expected Results: Allow the subfolder to be renamed.
I've seen this too. another thing that generates that message is to rename a folder to something with "/" in it. Seen it on Windows XP, in 1.4.
> 2.Randomly rename the subfolders. Are you using names which should be valid folder names? Can you give some examples of the new folder name? Also, when a rename fails, what happens if you completely exit Mozilla, restart it, and try the exact same rename operation? Does it still fail?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think this is another case of the CRTL rename bug which is reported elsewhere as a problem emptying the cache. Basically a rename of a directory fails. See CRTL_INTERNAL 2024 for details. What this means for Mozilla Mail is that a folder can be renamed just so long as it doesn't contain any sub-folders. This is because a folder without sub-folders is just a couple of files on disk, and the rename of the files succeeds. But when a folder contain sub-folders, then a directory is used on disk for the contents of the sub-folder, and when you attempt to rename the folder the files on disk get renamed but not the directory. This leaves the folder in an inconsistant state and Mozilla gets very confused, hence the problems you are seeing. For example, I had a folder BILL which contained sub-folders. On disk I had: BILL. BILL.MSF BILL_SBD.DIR After the attempted folder rename to FRED I had: FRED. FRED.MSF BILL_SBD.DIR That is not good. I will push some more on the CRTL folks to get a resolution to this problem.
Assignee: sspitzer → colin
Good news, bad news. The good news is that I got a response from the CRTL people and its possible to get rename to exhibit the behavour we expect. Bad news is that with one problem solved it just moved us on to the next problem. Now the rename is failing because of the problem described in bug 187964. The details which are really only of use to me at this point are as follows. The directory is actually named foo.sbd in the code and when its created the OpenVMS mkdir jacket routine converts that name to foo_sbd (for ODS-2 compatibility). But when the rename("foo.sbd","bar.sbd") call is made the rename jacket doesn't know that these are both directory files (they are both valid ODS-2 filespecs) and so the "." is not converted to a "_", and therefore the rename fails. The real fix is to make the ".sbd" postfix be platform specific, and this is what bug 187964 is all about. Its *possible* that we might be able to work around this in the rename jacket, but I need to think about what might break if we were to do this.
Status: NEW → ASSIGNED
Depends on: 187964
In case you've attempted to rename a folder containing sub-folders, and lost the sub-folders as a result, here's how to get them back. For this example, assume the old folder name was "old" and that the new folder name is "new", and that the profile being used is named "profile" (note that if you haven't created additional profiles then your (only) profile should be named "default"). $! make sure Mozilla/CSWB is not running $! $ SET DEFAULT SYS$LOGIN $ DIR [._MOZILLA.profile...MAIL...]old_SBD.DIR $ SET DEFAULT <directory where old_SBD.DIR resides> $ RENAME old_SBD.DIR new_SBD.DIR $! $! restart Mozilla/CSWB
The other way you can get back "lost" sub-folders is to rename the parent folder back to its original name.
Steve, you indicated in a mail yesterday that my explanation in comment 3 doesn't explain the behaviour you are seeing. In that case I'm going to need more information about how to reproduce this problem. Starting with a clean set of mail directories (not one which has been corrupted by the problem described in comment 3), and being careful not to cause the bug described by comment 3 (ie. do not rename any parent directories), please tell me exactly what you do in order to get into a situation where folders can not be renamed.
Two weeks and no reply. Steve, if this is still a problem, please re-open and supply the requested information.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.