Bug 73097 - displaying of smbmounted directory realy slow
Summary: displaying of smbmounted directory realy slow
Status: RESOLVED WORKSFORME
Alias: None
Product: kio
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2004-01-21 02:31 UTC by Jarne Cook
Modified: 2018-10-29 02:22 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jarne Cook 2004-01-21 02:31:10 UTC
Version:           3.1.5 (using KDE 3.1.5)
Installed from:     (testing/unstable)
Compiler:          gcc version 3.3.3 20031229 (prerelease) (Debian)
OS:          Linux (i686) release 2.6.0-test7

OK ... get this

I can only assume the problem has something to do with the file io.

I have a directory with 2 different methods of accessing it. 
One is via mount -t smbfs and the other is using the smb io.
smb://sr-131/kazaafolder
file:/mnt/smb/sr-131/kazaafolder

Now ... this dir has a shit load of entries in it ... lots of .dat files.

I assume that what is ...
if method = "file://" ... then get real file type using a smilar method to 'file'.  
else if the method is something slow like smb:// ... the use the extention to figure the file type ... even though I had disabled showing that column.

Yes ... that must be it ... just looked at the smb window ... all the .dats type are "unknown" ... where as the file:// window hash whatever would be in there ... eg MPEG Video

Now ... what gets me ... is that anyone would ever consider using a 'file' type system to figure out a file type.  Maybe if there was no extention ... i could understand that ... but what? ... MS use file extentions to determine the file type ... so ... we wont do it that way ... /me shakes my head

How about this ...
we have an option for figuring out file type

O inspect all files ( i assume that is the default
  for file://)
* use file ext database and fall back to inspection
  if filetype unknown
* use file ext. database exclusively.  
    Unkown file types to be marked as 
    * uknown
    0 blank


what ya reacon?
Comment 1 Jarne Cook 2004-01-21 02:34:26 UTC
damn spacing ... ill redo that last bit

O inspect all files ( i assume that is the default for file://) 

* use file ext database and fall back to inspection if filetype unknown 

* use file ext. database exclusively. 
__Unkown file types to be marked as 
__* uknown 
__0 blank 
 
 
Comment 2 Stephan Kulow 2004-01-21 12:55:18 UTC
we do basically exactly that. We just don't do it for remote files and smb:/ is one of those
Comment 3 Jarne Cook 2004-01-21 23:06:10 UTC
Subject: Re:  displaying of smbmounted directory realy slow

On Wednesday 21 January 2004 21:55, you wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>       
> http://bugs.kde.org/show_bug.cgi?id=73097      
> 
> 
> 
> 
> ------- Additional Comments From coolo@kde.org  2004-01-21 12:55 -------
> we do basically exactly that. We just don't do it for remote files and smb:/ 
is one of those

But it _is_ happeing for remote files as /mnt/smb/..... is being considered 
local ... but its not ... its a smbmount'ed dir.

See what im sayin'?



> 

Comment 4 Stephan Kulow 2004-01-22 11:50:10 UTC
so this got nothing to do with the slave
Comment 5 Jarne Cook 2004-01-22 23:11:57 UTC
Subject: Re:  displaying of smbmounted directory realy slow

On Thursday 22 January 2004 20:50, you wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>       
> http://bugs.kde.org/show_bug.cgi?id=73097      
> coolo@kde.org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>          AssignedTo|neundorf@kde.org            |faure@kde.org
>            Severity|normal                      |wishlist
>           Component|smb                         |general
> 
> 
> 
> ------- Additional Comments From coolo@kde.org  2004-01-22 11:50 -------
> so this got nothing to do with the slave

Id belive it's the file io slave with the problem ... or whatever uses the 
that ... its the one who's taking for ever ... so id have to ass-u-me  :-) 
that the "file" io slave (is that even a slave?) ... is not discrimanent 
about what files it "inspects".

smb:// is fine ... till you get kplayer to open a 700Mb file ... but that is a 
different story.

essentially ... file:// shouldn't just assume it should inspect every file.

> 

Comment 6 Nate Graham 2018-04-23 16:01:28 UTC
Is this still relevant or applicable with KDE Frameworks 5.45?
Comment 7 Andrew Crouthamel 2018-09-28 03:33:52 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 8 Andrew Crouthamel 2018-10-29 02:22:17 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!