The first charactor is eaten when listing "C:/"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. launch hotwire
2. cd C:/
3. ls

What is the expected output? What do you see instead?
I expect it to list the entries in this directory correctly. while the
first character is eaten when entries are shown. e.g. boot.ini is shown as
"oot.ini"

What version of the product are you using? On what operating system?
svn r874 on windows with python 2.5.1

Please provide any additional information below.
In order to get a complete list of the entries, I need to apply this patch:
Index: ls.py

===================================================================

--- ls.py   (revision 874)

+++ ls.py   (working copy)

@@ -41,13 +41,17 @@

     def __ls_dir(self, dir, show_all):
         fs = Filesystem.getInstance()
         for x in iterd_sorted(dir):
-            if show_all:
-                yield fs.get_file_sync(x)
-            else:
-                bn = os.path.basename(x)
-                if not (fs.get_basename_is_ignored(bn)):
+            try:
+                if show_all:
                     yield fs.get_file_sync(x)

+                else:
+                    bn = os.path.basename(x)
+                    if not (fs.get_basename_is_ignored(bn)):
+                        yield fs.get_file_sync(x)
+            except:
+                pass
+
     def execute(self, context, args, options=[]):
         show_all = '-a' in options
         long_fmt = '-l' in option

Otherwise the following exception raised and the entry list is shorten:

16:30:01 [4856] hotwire.Command ERROR Caught exception: [Error 13] The
process c
annot access the file because it is being used by another process:
u'c:/hiberfil
.sys'
Traceback (most recent call last):
  File "C:\tools\hotwire-shell-read-only\hotwire\command.py", line 312, in
__run

    for result in self.builtin.execute(self.context, *target_args, **kwargs):
  File "C:\tools\hotwire-shell-read-only\hotwire\builtins\cd.py", line 59,
in ex
ecute
    for result in BuiltinRegistry.getInstance()['ls'].execute(context,
[new_dir]
):
  File "C:\tools\hotwire-shell-read-only\hotwire\builtins\ls.py", line 75,
in ex
ecute
    for x in generator:
  File "C:\tools\hotwire-shell-read-only\hotwire\builtins\ls.py", line 51,
in __
ls_dir
    yield fs.get_file_sync(x)
  File "C:\tools\hotwire-shell-read-only\hotwire\sysdep\fs.py", line 61, in
get_
file_sync
    f.get_stat_sync()
  File "C:\tools\hotwire-shell-read-only\hotwire\sysdep\fs.py", line 275,
in get
_stat_sync
    self._do_get_stat(rethrow=True)
  File "C:\tools\hotwire-shell-read-only\hotwire\sysdep\fs.py", line 291,
in _do
_get_stat
    raise FileStatError(e)
FileStatError: [Error 13] The process cannot access the file because it is
being
 used by another process: u'c:/hiberfil.sys'

Original issue reported on code.google.com by Zeng.Shi...@gmail.com on 25 Jan 2008 at 10:32

[GoogleCodeExporter]

Well, I don't want to just always ignore errors during 'ls' because that would 
hide
things you do want to see; for example if you don't have permission to see a 
file,
you want to know why.

Windows has a concept of hidden files, I think.  Probably the best solution 
here is
to skip them unless you specify -a, just like how we hide files starting with 
'.' on
Unix.
I took a look at MSDN, here is the .NET API:
http://msdn2.microsoft.com/en-us/library/system.io.file.getattributes(VS.71).asp
x

But we need to figure out how to get the file attributes from Python.  Hm...ah 
hah! 
Google to the rescue:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303343

So we need to figure out how to best use that.  That should fix the 'ls' error. 
 It
looks like it's throwing if we just call os.stat() on it, so we have to do 
something
before that.

Maybe the method get_file_sync() needs to have an optional flag like
stat_hidden=True, and "ls" will pass False for that if the option '-a' was not
passed.  Then inside the Win32File implementation, we override _do_get_stat, and
check using win32api.GetFileAttributes(self.path, 
win32con.FILE_ATTRIBUTE_HIDDEN)
whether the file is hidden or not.  If it is - then we throw an exception such 
as
FileHiddenError, and "ls" knows to ignore it.

Now as for the first character being stripped...that bug is in
hotwire_ui/renderers/file.py, function _render_objtext.  That function is 
assuming
that the filesystem root is one character long.  I'm not totally sure how to 
fix this
one cleanly.  Maybe we could do something ugly like checking with is_windows() 
and
looking to see if the path is of the form [A-Z]:/  But that's ugly...

Original comment by cgwalt...@gmail.com on 26 Jan 2008 at 12:53

• Changed state: Accepted

[GoogleCodeExporter]

Is this patch OK? I assume it already requires python 2.5, I used conditional 
statements.

Index: file.py
===================================================================
--- file.py (revision 885)
+++ file.py (working copy)
@@ -28,6 +28,7 @@
 from hotwire_ui.render import TreeObjectsRenderer, ClassRendererMapping, menuitem
 from hotwire.sysdep.fs import Filesystem, File
 from hotwire.sysdep.sysenv import SystemEnvironment, GnomeSystemEnvironment
+from hotwire.sysdep import is_unix, is_windows
 from hotwire.logutil import log_except
 from hotwire_ui.pixbufcache import PixbufCache
 from hotwire_ui.adaptors.editors import EditorRegistry
@@ -133,8 +134,11 @@
         obj = self._file_for_iter(model, iter)
         path = obj.path
         if self.__basedir:
+            bdir = self.__basedir if not is_windows() \
+                   else os.path.splitdrive(self.__basedir)[-1]
+                
             # Strip leading / unless we're in root
-            if len(self.__basedir) > 1:
+            if len(bdir) > 1:
                 offset = 1
             else:
                 offset = 0 

Original comment by Zeng.Shi...@gmail.com on 26 Jan 2008 at 3:56

[GoogleCodeExporter]

I'm trying to keep Hotwire working on Python 2.4 actually because there are some
major systems like Debian Etch and Red Hat EL5 still using 2.4 =/

2.3 though didn't have generators, so 2.4 is the oldest we go for sure =)

I changed this patch around a bit to make it work on 2.4, and also I tried to 
avoid
calling is_windows() and splitdrive() too often.  I think the GtkTreeView can 
call
the rendering function many times.

Thanks very much for this patch, I hope my tweaks to it keep it working:

Committed r886
    M   hotwire_ui/renderers/file.py
r886 = d2dd5eaa475f6a202a1e4a435399dc9955cc7713 (git-svn)

I'm going to move some of the comments about the hiberfil.sys to a new bug...
http://code.google.com/p/hotwire-shell/issues/detail?id=131

Original comment by cgwalt...@gmail.com on 26 Jan 2008 at 4:11

• Changed state: Fixed