Showing posts with label folder. Show all posts
Showing posts with label folder. Show all posts

Monday, April 2, 2012

Windows 7: Eliminating "This Folder Is Shared With Other People" Message

I had installed Windows 7.  Now, when I would try to move or delete some folders, I would get this message:

This folder is shared with other people.

If you move this folder, it will no longer be shared.
That message was correct:  I had, in fact, shared the parent folder (and all of its subfolders, including this one) with my other computer.  And I wanted existing and newly created subfolders to continue to be shared.  I just didn't want to receive this warning.

I tried the approach of going into Control Panel > HomeGroup > Leave the homegroup, because someone advised that this was the solution.  It wasn't.  I tried a search.  This led to a thread with some heartwarming rants about what a dumbass feature this was.  That thread also contained the suggestion that, at least for purposes of deleting (as distinct from moving) folders, a workaround was to cut and paste files and folders into Recycle Bin, rather than trying to delete them directly.  There was also a command line alternative that supposedly worked for wiping out lots of subfolders:
for /D %d in (*) do rmdir /S /Q "%d"
My guess was that the command line would also work for moving, in a pinch:  type MOVE /? for guidance.  But I didn't want a command-line solution.  The thread also offered a couple of other complicated workarounds with potential side effects.  Before going that route, I tried the suggestion to take ownership of the folder in question.  I had already added a Take Ownership context menu (i.e., right-click) option in Windows Explorer, so I used that now.  I used it at the level of the entire partition.  That didn't solve the problem.  I tried it again on the top-level folder.  That didn't do it either.  I verified that I had already given Full Control to Everyone in the Sharing context menu option, so that wasn't the solution either.

Another thread contained messages repeating the view that, as a deliberate feature of Windows, this couldn't be changed.  I took a look in TweakNow PowerPack 2012, in case they had a fix.  I hadn't really used TweakNow previously, but now I saw it wasn't really a tweaker in the sense that Ultimate Windows Tweaker (UWT) was.  So I ran UWT instead.  But no, UWT didn't seem to have a solution either.  So far, the only solution I had seen was that some people had repartitioned their drive and reinstalled Windows from scratch.  But that was a pretty draconian solution, and it didn't seem to guarantee against a recurrence of the problem.

Back in Windows Explorer, I right-clicked on the drive being shared and selected Properties > Security tab > Edit > Add > Everyone > Check Names > OK > Allow Full Control > OK.  That took a while, as it went through the drive, with a message that said, "Setting security information" various files and folders.  This was obviously not a very secure solution.  Nor was it logically related to sharing.  It was just a guess.

In another thread, someone said that they noticed this behavior began when they installed RC-1 (i.e., Windows 7, First Release Candidate).  As noted above, people had been saying it was a built-in Windows feature.  But there was at least the possibility that some program had triggered it.  In that spirit, someone else in that same thread offered the belief that it might be related to Windows Mail.  That was a possibility.  I had installed Windows Live Mail.  I didn't like it much -- it was very slow to start.  But I had already uninstalled it.  There didn't seem to be much more I could do on that front.  I tried running Glary Registry Cleaner, just in case that would make a difference.  It identified a lot of problems, but did not fix this particular one.  In another thread, someone suggested that the culprit might be the network sharing service in Media Player 11.

I saw recurrent references to the C:\Users\[username]\Appdata\Local\Temp\WPDNSE folder.  For username Ray, mine had nothing in it.  Evidently they came to that folder because its name was appearing in an error message.  I wasn't getting that.  The general idea seemed to be that one user might somehow be linked to another user at that folder.  That was interesting.  I looked into the possibility that this "shared folder" problem might be due to the existence of an unnecessary user account.  As described in another post, I pruned out some extraneous user accounts.  But that did not resolve this problem.

Over time, the problem appeared less frequently.  It seemed that there might have been an ownership or sharing event, occurring at one time, that became less relevant as my folders went through various processes of being renamed, moved, reshared, and so forth.  One post gave me the idea that the problem might be in Windows Explorer > select a folder > right-click > Properties > Sharing tab > Advanced Sharing > Permissions.  At this moment, the only group or user listed there was Everyone.  It seemed that, previously, there might have been additional entries there, for Ray, Administrators, and/or System.  The post made me think that, even though all roads seemed like they should lead to Mecca, the mere presence of multiple people here would confuse Windows.  Maybe the original warning that "This folder is shared with other people" was Windows' way of telling me that it was going to remove the others and leave only Everyone on the list.  I didn't test this; this was just an idea from that post.  At the time when I decided to close this post, it's not so much that the problem had disappeared as that it had become more rare.

Monday, January 9, 2012

Windows 7: Cannot Create New Folder in Windows Explorer

I was working along in Windows 7 x64, when suddenly I discovered that I could not create a folder in Windows Explorer.  The method I usually used (File > New > Folder) no longer existed:  the Folder option was gone from the drop-down menu.

A search suggested that I was not the only one who had experienced this.  It seemed that suggested solutions had not reliably fixed the problem.  One such solution was to download and run a REG file, and then reboot, to correct a problem in the registry.  I was concerned that such files could make a large number of registry changes, though, with unpredictable consequences, and that not all of those changes might be applicable to all versions of Windows 7.  A more conservative option was to add just one line to the registry, in a sub-subkey that might or might not already be present.  Specifically, the Default value of HKEY_CLASSES_ROOT\Directory\Background\shellex\ContextMenuHandlers\New was supposed to be {D969A300-E7FF-11d0-A93B-00A0C90F2719}.  But mine already was.  So the conservative registry edit wasn't the answer.

Someone had said something about creating a new folder by using the right-click context menu in Windows Explorer.  I had rarely if ever used that approach; and now that I tried it, I saw that the only New thing I could create there was a Briefcase, that holdover from ye olde versions of Windows.  I had often used Ctrl+Shft+N to create new folders, but that wasn't working either.  I ran a search to see if there were other ways to create a new folder, at least to buy some time until maybe a solution would occur to me.  One suggestion was to click on the new folder icon on the taskbar.  I didn't have that, I hadn't seen it, and pinning Windows Explorer to the taskbar didn't create it.  I suspected that perhaps the writer meant "command bar" (i.e., near the top of the Windows Explorer window), not the taskbar.  I did still have a New Folder option up there, but it wasn't working.  It seemed that the basic functionality was gone, regardless of where it might have been available previously.

It took me a while to realize that, of course, I could still create folders by opening a command window and using the "md" command.  Example:  md "\Folder name" -- where quotation marks were necessary because the folder's name had a space in it.  The hard way to open a command window in the folder where I wanted to create a subfolder was to go to Start > Run > cmd, and then navigate to the correct place by using commands like C: or D: to change drives, and cd "\Folder name\Subfolder name" to get where I wanted to go.  The easy way to open a command window in any folder was to go into Ultimate Windows Tweaker > Additional Tweaks > Show "Open Command Window Here."

But back to the missing ways of creating a new folder within Windows Explorer.  There were the inevitable suggestions to search for malware; but I wasn't getting any other weirdness, so malware seemed unlikely.  One discussion brought to mind the possibility that a recent program installation was responsible.  I played around with uninstalling and rebooting, but nothing clear emerged.  It seemed that I would have to restore Windows from a previous version, install upgrades and new programs as needed or desired, and see if I could track more closely when (or if) the problem reappeared.  But before doing that, I went ahead and ran the REG file mentioned above, the one that made many registry changes.  But when I did, I got an error:

Registry Editor

Cannot import D:\Current\NewFolderFix.reg:  Not all data was successfully written to the registry.  Some keys are open by the system or other processes.
I closed all windows that were still open, right-clicked on various icons down in the system tray and closed those, and tried again.  Still no luck.  I went to Start > Run > taskmgr.exe > Processes tab, closed down some processes that looked safe, and tried again.  It still wasn't enough.  I rebooted into Safe Mode and tried running the REG file there.  Same error!  I ran a search for the error message, but found no solution in the several pages I examined.  One hypothesis:  the REG file was not suited for this particular machine and/or version of Windows.

Eventually I did figure out what caused the no-new-folders problem.  It was a program called Boot Deleter.  It had a nifty option to associate itself with Windows Explorer, so that I could just right-click on a file that resisted being deleted by other means, and indicate that I wanted that file to be deleted the next time the system rebooted.  But now that I was watching carefully, the ability to create a new folder disappeared as soon as I clicked on the Associate button.  No real surprise that it would be problematic:  the program had not been updated since 2005.  I clicked, now, on the button to kill the association, but that didn't solve the problem:  the ability to create a new folder was not restored, even after a reboot.

Due to an apparent malfunction or misconfiguration, I discovered at this point that System Restore was not keeping current backups.  So now I would apparently have to restore a drive image from more than a month earlier.  Not a terrible thing, but I wondered if there was another way.  I hadn't used Revo Uninstaller, to watch what was being done when Boot Deleter was installed.  Boot Deleter hadn't installed a desktop icon or otherwise been visible, so I couldn't use Revo's Hunter Mode to figure out the problem.  But I could try reinstalling Boot Deleter, with Revo running, and see if it would work now.  I saw, then, that I would need the pro version of Revo for this, and I wasn't ready to spring for that.

Another possibility was to use Process Monitor (PM), which was said to track attempts to modify the registry.  I opened PM, maximized it, spread out its columns so that I could see what was happening, and went up to its toolbar.  I hovered over items to get their tooltips.  At the right end of the toolbar, I turned off a couple of items, so that I was monitoring only file and registry activity.  I went to Boot Deleter and got ready to install it again.  Back at the PM toolbar, I clicked on the Clear button, so that I wouldn't have too long a history to work through.  (I could also have used Ctrl-X to clear.)  Then I went back to Boot Deleter and installed it.  Then, back at PM, I clicked on the Capture button (Ctrl-E).  Then the Filter button (Ctrl-L).  In the Process Monitor Filter dialog, I deselected all of the items listed (e.g., "Process Name is Procmon.exe ... Exclude.").  In the first drop-down box at the top, I selected Process Name.  The second box said "is."  In the third drop-down box, I selected BootDeleter.exe.  The fourth box said "Include."  I clicked Add.  This put my BootDeleter.exe item in the list as the only checked item.  I clicked Apply > OK.  The status bar at the bottom of the PM screen told me that I now had a list of 2,345 events.  I went to File > Save.  "Events displayed using current filter" was already selected.  I changed the format to CSV and specified an output path and CSV filetype > OK.  In Windows Explorer, I double-clicked on that resulting file ("Process Monitor 01.csv"), and manipulated the file in Excel.  Basically, I filtered it for the items that looked like file or registry changes that would need to be reversed.  I wound up with a list of several hundred items.  Clearly, this was not going to be a matter of a few registry keys needing to be undone.  I decided it would be easier to restore the previous image, and catch up to the present that way.

Sunday, December 18, 2011

Thunderbird: The file Mailbox [filename] Cannot Be Found

I was using Thunderbird 3.1.16 in Windows 7.  I had a Hotmail account set up in T-bird, with the usual folders (Inbox, Drafts, etc.), and I also had a folder called E-mail Archive set up under Local Folders.  I was in the habit of removing messages from Hotmail's Inbox, when I was done with them, and storing them in the E-mail Archive folder.

Then I ran into a problem.  I clicked on a message in the E-mail Archive local folder and saw that there was no message body.  I could still see the From, To, Date, and all that, but the text of the message was gone.  At about the same time, I got an error message.  It said something like, "The file mailbox:///C|/Users[filename] cannot be found.  Please check the location and try again."

I ran a search.  It appeared that this was a pretty rare problem.  A different search led to a MozillaZine page that led me to think the problem was that I had not been compacting the E-mail Archive folder often enough.  The page said that compacting was a way to keep folders in good shape.  If I saw an email message with a weird date (e.g., sometime in 1969), that was a sign that the folder had become corrupted and should have been compacted.  I had indeed seen a message or two like that.  I had already set automatic compacting (Tools > Options > Advanced > Network & Disk Space), but apparently my value of 50MB (i.e., "Compact folders when it will save over 50000 KB") was too high.  So now I set that to 5MB instead.  It sounded like I would now be getting compaction prompts more frequently.  That webpage had advice on how to respond to this error message if the problem was with the Inbox, but that wasn't my problem.

Another MozillaZine page offered tips on how to set up and maintain Thunderbird.  I had stayed with version 3 instead of updating to a newer version of Thunderbird (currently 8.0 was the lastest) because I was using some add-ons that weren't compatible with the newer versions.  But this webpage seemed to offer a way around that.  So one possibility at this point was to upgrade and see if that would somehow solve the E-mail Archive folder problem as well.

Before doing that, it looked like there might be something I could do to retrieve the E-mail Archive folder within my existing setup.  One thread gave me the impression that an email folder might consist of a pair of files, working together.  One would have a name like REMC#1.msf, and the other would be REMC#1 (without the .msf extension).  I used Everything to search for *.msf files.  My system had 34 of them, all in the Thunderbird folder.  Originally, it seemed, the default installation location for Thunderbird in Windows 7 was at C:\Users\<account>\AppData\Roaming\Thunderbird\Profiles\[8 random characters].default, but I had moved that folder to drive D.  Specifically, I saw an E-mail Archive.msf file in that folder; but when I searched again for that filename, there wasn't an accompanying E-mail Archive file (without the extension).  I did have a backup of one, though.  It was big -- 500MB, apparently containing my tons of emails that should have been compacted.  So now I closed Thunderbird, copied that backup file (i.e., E-mail Archive) to the Thunderbird folder alongside E-mail Archive.msf, moved (instead of deleting) the E-mail Archive.msf as advised, and started T-bird again.

While doing the necessary screwing around in vague efforts to find a possible solution, I had already closed T-bird once before, after discovering the problem with the E-mail Archive folder, and when I started T-bird again, that folder was completely gone.  My guess was that the *. file (that is, E-mail Archive, without the extension) was responsible for telling T-bird that it should display a folder called E-mail Archive.  So when that non-extension file disappeared, so did Thunderbird's indication that I was supposed to have a Local Folders folder called E-mail Archive.

But now that I had copied the E-mail Archive *. file from backup to the Thunderbird folder, I did once again have an E-mail Archive folder visible under Local Folders.  I clicked on it.  The status bar said "Loading message . . ." for a minute, and then it was ready to show me the message bodies (i.e., the text of my email messages) once again.  So, wow, problem solved.  I dragged a boatload of messages from the E-mail Archive folder to another local folder.  I did that because it seemed that the E-mail Archive folder had gotten too big to work properly, so I wanted to reduce its contents before doing anything else.

Some months earlier, I had undertaken a project to remove old emails from Thunderbird and put them into individual PDF files.  It was convenient to have recent emails in T-bird, where I could quickly search for and reply to them.  But as messages got older, it was less likely that I would be using them for that sort of search and reply.  I decided to create a Thunderbird local folder called Ready to Archive, and I moved all messages older than six months into that folder.  I was a little superstitious about the E-mail Archive folder, so I decided to replace it with a new folder called Email Archive (without the hyphen). So I moved the messages that were less than six months old into Email Archive.  Now the E-mail Archive folder was empty.  Searches in Everything now showed that my new folders -- Ready to Archive and Email Archive -- were a couple hundred megabytes each.  Together, their sizes came close to the total size of the old E-mail Archive folder, and the combined numbers of emails in those folders (as displayed in the status bar at the bottom of the Thunderbird window) added up to approximately the correct total.  (I didn't think of recording the exact number before moving those items out of the old E-mail Archive folder.)  So it looked like things had worked out.  (Everything showed that the old E-mail Archive folder was still huge, but I guessed that compaction would probably shrink it down to almost nothing, if I had bothered to compact it.)

Deleting the E-mail Archive folder was not as easy as I thought it should be.  This folder had a different icon than the ones I had just created.  Maybe that explained why there was no right-click Delete option for this folder, and the Delete key didn't work.  I went into this folder's right-click > Properties and saw that there was a Repair Folder button that, according to the information provided there, might repair the .msf index file.  Nice to know, but I didn't need it anymore.  I closed Thunderbird, went into Everything, deleted the E-mail Archive and E-mail Archive.msf files, and restarted Thunderbird.  Now the E-mail Archive folder was gone, and the new Email Archive and Ready to Archive folders seemed to be working properly.

I closed Thunderbird, backed up the Thunderbird folder, and decided that my next projects in this area would be, first, to see if the advice cited above would work -- if I could upgrade T-bird while keeping my add-ons -- and, second, to take another shot at a hopefully streamlined process for that project (above) of converting old emails into PDFs.

Friday, March 25, 2011

Windows 7: Item Not Found Error

Suddenly, when I was moving folders, I started getting a stupid message that the folder that I was moving was no longer where it used to be.  The message was specifically as follows:

Item Not Found
Could not find this item
This is no longer located in [source folder].  Verify the item's location and try again.
Trying again would finish the move.  I wanted to stop getting this message.  I ran a search and came up with a thread suggesting that the problem was with a Windows 7 update, KB980408.  That thread led me to a .reg file, which I downloaded and ran:
Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{2112AB0A-C86A-4ffe-A368-0DE96E47012E}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{2112AB0A-C86A-4ffe-A368-0DE96E47012E}\PropertyBag]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{491E922F-5643-4af4-A7EB-4E7A138D8174}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{491E922F-5643-4af4-A7EB-4E7A138D8174}\PropertyBag]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{7b0db17d-9cd2-4a93-9733-46cc89022e7c}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{7b0db17d-9cd2-4a93-9733-46cc89022e7c}\PropertyBag]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A302545D-DEFF-464b-ABE8-61C8648D939B}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A302545D-DEFF-464b-ABE8-61C8648D939B}\PropertyBag]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A990AE9F-A03B-4e80-94BC-9912D7504104}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A990AE9F-A03B-4e80-94BC-9912D7504104}\PropertyBag]
That seemed to take care of it.

Wednesday, January 5, 2011

Windows 7: A Futile Attempt to Move the Fonts Folder

In Windows 7, I tried to move the C:\Windows\Fonts folder to another location.  I did it because I didn't want to lose fonts, if I decided to install additional ones.  At the default C:\Windows\Fonts location, they wouldn't survive reinstallation of the system.  An alternative was to save copies of additional fonts at a different location and copy them to C:\Windows\Fonts after installing a new system.

I found no guidance on this process of moving the Fonts folder.  I copied everything from the C: folder to the X: folder.  Then I searched the registry, changed the references in my .reg file to the new location (X:\Cache\Fonts) in the two locations where I found references to C:\Windows\Fonts, and ran the reg file.  The system rebooted without a problem.  I tried to delete C:\Windows\Fonts, but that gave me a message:

Folder Access Denied
You need permission to perform this action.
You require permission from TrustedInstaller to make changes to this folder.
I searched on that and found advice to go into right-click Properties > Security tab > Advanced > Owner tab.  There was no such tab for C:\Windows\Fonts, but there was for C:\Windows.  I went to Edit, changed it to Administrator, and checked "Replace owner on subcontainers and objects."  When I clicked Apply, I got another message:
Windows Security
You do not have permission to read the contents of directory C:\Windows\CSC\v2.0.6.  Do you want to replace the directory permissions with permissions granting you Full Control?
All permissions will be replaced if you press Yes.
The answer seemed obvious, and that made me suspicious.  I searched on that and saw that Microsoft advised to just go ahead with this, in a couple of contexts, so I did.  It took a while to change permissions for everything in C:\Windows.  Next, I got a message telling me to close and reopen properties to see the updated situation, so I did that.  Still looking at Properties for C:\Windows, I went into Security tab > Edit.  I highlighted Administrators and then clicked Allow for Full Control.  Now I got a message saying, "You need permission to perform this action" -- permission from Administator, which I was.  I found other advice that seemed to recommend these two commands:
takeown /f C:\Windows\Fonts
cacls C:\Windows\Fonts /G Administrator:F
But when I then tried to delete, I got another error message:
Folder In Use
The action can't be completed because the folder or a file in it is open in another program.
Close the folder or file and try again.
Not surprising, since the system itself was obviously using fonts, though it would seem like it could have been just as happy using them from X: as from C:.  I thought I had rebooted since making the registry change, so this time I booted into Safe Mode and tried the deletion there.  No joy.  I selected all fonts and tried deleting them individually, and that got me down to a selected core of 81 fonts, including essentials like Sylfaen Regular and Utsaah.  I was tempted to boot into Ubuntu and wipe out the Fonts folder that way, but instead I gave up:  I went to X:\Cache\Fonts and copied all of the fonts back to C:\Windows\Fonts.  I couldn't remember exactly how many there had been, but the count didn't seem the same, so I rebooted into Normal mode to run System Restore.  My hunch was correct:  some fonts were not displaying correctly.  After System Restore, all was lovely, so I moved on to the next part of my life.

Wednesday, September 29, 2010

Ubuntu 10.04: Sharing a Folder on an NTFS Partition

I had two computers running Ubuntu 10.04.  These machines were connected by ethernet cable through a router.  Both had Samba installed, and both had a shared folder set up as described in another post.  I had set up one of those shared folders on an ext3 partition.  As that other post indicates, I was able to see the contents of that shared folder from the other computer.  But without thinking about it, I had set up the other computer's shared folder on an NTFS partition.  Seeing a folder on that partition turned out to be a more complicated matter than I had expected.  This post describes my efforts in that regard.

Right away, I rediscovered that chown wouldn't work as expected with NTFS drives, and that it was therefore necessary or advisable to type "sudo gedit /etc/fstab" and change the lines for NTFS drives or partitions to something like this:

UUID=[UUID for the drive] /media/partitionname ntfs-3g rw,suid,dev,exec,auto,user,async,umask=000 0 0
and then unmount ("sudo umount /media/partitionname") and remount the partition.  Remounting would apparently force a look at the new contents of fstab, and could be done with "sudo mount /dev/sdc3 /media/drive1" or just "sudo mount -a" (assuming a folder named /media/drive1 had already been created (e.g., "sudo mkdir /media/drive1")).  That fstab line was one I had developed to replace the "defaults" word that appeared in some fstab lines previously:  it made all of the default settings explicit, and changed some of them.  Yet even with this change, when I tried to set the Sharing Options in Nautilus, I got this error message:
Folder Sharing

'net usershare' returned error 255: net usershare add: cannot share path /media/partitionname/folder2 as we are restricted to only sharing directories we own.

Ask the administrator to add the line "usershare owner only=false" to the [global] section of the smb.conf to allow this.
I was willing to go into smb.conf and make that change, but first I wanted to know why (as I confirmed with a right-click > Properties) root still owned that folder.  This led to the insight that NTFS filesystems (such as the one I was trying to share) did not remember ownership, so the partition would need to be reminded each time I mounted it.  One way to do this was to modify the fstab line to include user and group identifications:
UUID=[UUID for the drive] /media/partitionname ntfs-3g rw,suid,dev,exec,auto,user,async,umask=000,uid=username,gid=groupname 0 0
and then save fstab and unmount and remount the partition (above).  And yet that still didn't do it.  The better statement seemed to be, not that NTFS partitions needed to be reminded, but that they simply didn't have an ownership concept.  There seemed, then, to be no alternative but to type "sudo gedit /etc/samba/smb.conf" and add the line "usershare owner only=false" to its [global] section, as advised above.  I saved and closed that and tried Sharing Options again.  This time it worked, or at least it didn't give me an error message.

Unfortunately, the shared folder still wasn't showing up on the other computer's Places > Network list.  It sounded like the solution might be to try Sharing Options as root ("sudo nautilus").  Unfortunately, at this point "sudo nautilus" was giving me an error message on that computer:
(nautilus:23890): Unique-DBus-WARNING **: Error while sending message: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
I wondered what would happen if I stepped away from the NTFS situation for a moment.  I decided to try sharing a folder on an ext3 partition in that same computer.  I right-clicked on the ext3 partition in Nautilus, chose Create Folder, named the folder, went to the Share tab, and selected "Share this folder" and "Allow others to create and delete files in this folder."  This gave me an error message:
'net usershare' returned error 255: net usershare add:
cannot stat path /media/partitionname/foldername to ensure this is a directory.  Error was No such file or directory
I guessed that this might be because I had gone directly to the Share tab without first clicking Close in the Basic tab there in the P4 Share Properties dialog.  So, OK, I saved the new folder first, and then right-clicked on it in Nautilus and chose Sharing Options.  This time it went OK.  I went into System > Administration > Samba, as described in the other post, and added this folder there.  But I still wasn't able to see it from the other computer.  I rebooted this problematic machine and tried again.  In doing so, I noticed that GParted and some other things were still running on another desktop, so that may have explained why "sudo nautilus" worked OK after the reboot.  The sharing step just described also worked OK.  But Places > Network on the other computer still didn't show the problematic computer.  

I was just about to change some hardware and reinstall Ubuntu on that machine anyway, so I deferred further effort on this project until after that was done.  At that point, though, I found a better folder-sharing solution by using a Synology network-attached storage (NAS) unit.