New Folder, CIFS, and scroll problems
Brought to you by:
axeld
Menu
▾
▴
#40 New Folder, CIFS, and scroll problems
The "new" option on the right-click menu in tracker, used for
creating new folders, or file templates, almost always
dissapears when working on directories other than the desktop.
I have not been able to trace this occurance to anything in
particular, but it happens so frequently (the new option is
absent much more than it is present) that I need to keep an
empty directory on the desktop just so that I can make new
folders. This occurs on each of the four machines I've tested
on, all with BeOS Personal Edition R5.0.3.
This problem has been around for quite a while now, in
multiple Open Tracker releases, although the original Be
tracker doesn't have the problem (since it doesn't have a pop-
out menu for new). Btw, the pop-out menu should really be a
user-configurable option; I find it's more of a pain than a
help personally.
I have also noticed a problem related to mouse-wheel
scrolling, although it crops up nowhere near as frequently.
Very occasionally, the mouse wheel gets "undergeared" --
moving the mouse wheel a huge amount seems to move the tracker
view only a few pixels -- in fact, about one pixel per click.
Also, related to scrolling, Open Tracker sometimes doesn't
display the scrollbars or allow scrolling in a directory that
actually contains more files than you can see. Instead, you
have to wobble the resize on the window around until the
scrollbar gets enabled and you can scroll.
Finally, BeOS R5 isn't known for its quality of networking,
but Tracker (including the original Be version) has always
exhibited problems with CIFS (SMB, SAMBA) shares, which don't
crop up in the terminal. Apart from the extremely regular
crashes and timeouts when working with CIFS, Tracker is
actually *destructive* to data when working on an SMB server.
Not only is it destructive, but it continues causing data loss
on the server EVEN when the server is set to share the drive
as *read only*! Unlike the other bugs, this happens all the
time; I have never seen a case where this does not happen.
The data loss I speak of refers to the file's metadata;
specifically the dates attached to the files. Every time
Tracker "sees" a file on an SMB share (either in a file
selector, or Tracker window) it *destroys* the date beyond
repair, setting it to the current day, regardless of the
server's share priveleges. From what I've seen, this happens
with SAMBA (under FreeBSD and Linux), Windows 95 and Windows
98 acting as the server. Again, non-tracker apps (the
terminal, NetPenguin, etc) do not have any of these problems -
- SMB shares are reliable and do not cause data loss.
This bug is a particularly nasty one; it's bad enough loosing
dates on your home computer, but corrupting dates on a server
which you may not even own is a hanging offence. With almost
any server, the dates will be important; not just to the
users, but also to automated backups.
I'm not sure where the problem lies excatly (in Tracker, or
the networking file system), but clearly Tracker is doing
something to the files and folders that everything else (the
terminal, NetPenguin, and other apps which don't use Tracker
for listing files) doesn't do. If the problem does not lie
with Tracker, then it would still be highly desirable to have
an option to turn off whatever Tracker is doing to each file
as it lists them, to avoid this.
Logged In: YES
user_id=27501
First of all, you should file several bug requests if you report
bugs, but thanks anyway :-)
1.) Can't reproduce that one - the "New" menu only shows up if you
click on a free space, it's not in the context menu of a file or
directory. And it won't up in the Trash, or in a Query window.
Other than that, I think it's a good idea to make that item user
configurable, too - at least I am not using it at all.
2.) I also haven't noticed that one. Does it happen in other
applications, too, or is it an OpenTracker exclusive feature? :)
3.) I've seen that, too, but I haven't found the time to look into
it yet. Might have to do with messages getting lost.
4.) This is not a Tracker problem! Obviously, the Be API
implementation is different from the Posix implementation (both use
the internal kernel interface); While the POSIX API just return an
error, the Be API hangs, and it's not possible to determine an
error with it before - I tried many different checks, without any
luck.
Using CIFS *is* unstable, there is no way to deny that, but it's
not Tracker's fault. Also, the date updating problems you speak of
are most likely a bug on both sides (cifs because it tries to
update the dates, and samba because it allows that for read-only
shares).
I don't think we will be able to fix anything of this before
OpenBeOS.
Logged In: NO
Sorry about the multiple-item report!
Regarding the New Folder creation problem I mentioned above, I have
obtained some screen captures, along with some more information
about the problem. You can see these screen captures (Requires a PNG
translator) along with the information at the following URL:
http://littlebluerodent.tripod.com/bfs.htm
The problem certainly also crops up when clicking in free space, as
well as when inside a directory inside a FAT partition (as opposed
to the root directory, depicted in the screen captures).
Regarding the mouse-wheel scrolling issue, I haven't seen this
appear often enough to test it. It's possible it may also appear in
other BeOS applications, although I believe Netpositive is immune.
The reason I suspect this is because Netpositive is probably the
most used application on this machine; even more so than Tracker,
and I haven't seen the problem crop up in Netpositive.
As for the CIFS issue, it's certainly interesting that the problem
is usually only seen in Tracker, but I can understand that it would
crop up if Tracker is using a fundementally different method to
communicate with the kernel.
As a side note, would it be possible to optimise the speed at which
directories display in Tracker? I'm not sure if the bottleneck lies
with Tracker, but it seems fairly sluggish when rendering a
directory with more than 100 files; this is the case on any Tracker
version; OT or standard Tracker. This is perhaps slightly more
irritating when using the file selector than the main Tracker, but
it's still quite slow compared to, say, File Manager from Windows.
It's less of an issue on my Athlon 1330 than it was on my K6 233,
but it's still a bit of an issue. However, other applications, such
as Netpenguin, also take a bit of time to render directories, so it
might not be a Tracker issue at all. I'm not really aware of BeOS'
internal workings, so I hope I'm not being too counter-productive
here!
Logged In: YES
user_id=699744
I also noted the first problem.
I got it this way: When you choose that the Tracker should
display on the desktops the "Disks" folder that contains the
mounted disks, you get the problem when you navigate
starting from this folder. You can only avoid when you open a
folder by using a link or by disabling the "Disks" folder, so
every disk is shown on the desktop.
Logged In: YES
user_id=27501
Yes, the problem is the broken inheritance of the Disks window in
combination with single window browsing.
As for the speed of opening directories: I am pretty sure it could
be greatly sped up in general - at least I am also very unconfident
with it now. But I doubt that we could match the speed on Windows
Explorer due to the differences in the file systems (and the
current underlying architecture as well).