Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#232 W2003 explorer crash with long filenames

open
nobody
None
5
2012-11-29
2007-03-04
Anonymous
No

Hello,

when using drive redirection from a linux host to a
windows 2003 terminal server, the windows explorer
crashes when files with names longer than approx.
128 chars are in a traversed directory.

Simply skipping files with names longer than this
solves the problem

Example patch

--- disk.c.orig 2007-01-08 05:47:05.000000000 +0100
+++ disk.c 2007-03-02 10:48:16.000000000 +0100
@@ -1135,8 +1135,9 @@
}

/* find next dirent matching pattern */
+ /* ignore files with filename too long */
pdirent = readdir(pdir);
- while (pdirent && fnmatch(pfinfo->pattern, pdirent->d_name, 0) != 0)
+ while (pdirent && (fnmatch(pfinfo->pattern, pdirent->d_name, 0) != 0 || strlen(pdirent->d_name) > 118))
pdirent = readdir(pdir);

if (pdirent == NULL)

Discussion

  • Christoph Peus
    Christoph Peus
    2007-09-05

    Logged In: YES
    user_id=958360
    Originator: NO

    The problem occurs with file names longer than 126 characters to be precise.

    But simply skipping them is *not* a solution. Users expect USB-Sticks to behave always the same - no matter whether they are plugged into a Windows fat client or a Linux/rdesktop based thinclient device. One may think that it is not often that a user chooses a filename with more than 126 characters, but if users save documents with automatically generated filenames (e.g. when saving websites) this occurs quite frequently, at least in our public pc pools. Typical scanario: they save something to a USB-Stick at home (using standard Windows pc of course) plug that stick into one of our thinclient devices and cannot open the file because the connection crashes or - if above path would be applied - the saved file wouldn't be displayed - very annoying.
    Please please please fix that bug!
    Thanks.

    Regards
    Christoph

     
  • Logged In: NO

    BAD idea. With this patch filenames longer than 128 bytes works correctly

    --- disk.c.orig 2008-03-31 15:45:39.000000000 +0400
    +++ disk.c 2008-03-31 15:44:53.000000000 +0400
    @@ -1197,8 +1197,8 @@
    out_uint32_le(out, fstat.st_size); /* filesize low */
    out_uint32_le(out, 0); /* filesize high */
    out_uint32_le(out, file_attributes);
    - out_uint8(out, 2 * strlen(pdirent->d_name) + 2); /* unicode length */
    - out_uint8s(out, 7); /* pad? */
    + out_uint16(out, 2 * strlen(pdirent->d_name) + 2); /* unicode length */
    + out_uint8s(out, 6); /* pad? */
    out_uint8(out, 0); /* 8.3 file length */
    out_uint8s(out, 2 * 12); /* 8.3 unicode length */
    rdp_out_unistr(out, pdirent->d_name, 2 * strlen(pdirent->d_name));

     
  • Logged In: NO

    > Date: 2008-03-31 11:56
    > Sender: nobody
    > Logged In: NO

    > BAD idea. With this patch filenames longer than 128 bytes works correctly

    Thanks a lot!!! Great patch. Works correctly

     
  • Lenar Shakirov
    Lenar Shakirov
    2008-07-04

    Logged In: YES
    user_id=2135935
    Originator: NO

    > Date: 2008-03-31 15:56
    > Sender: nobody
    > Logged In: NO

    > BAD idea. With this patch filenames longer than 128 bytes works correctly

    Thanks! Its work very cool!

     
  • Hello everybody !
    For me, this bug is not corrected yet ! (I have tested it with rdesktop 1.5.0 and 1.6.0)

    Steps to reproduce :
    1) connect to a W2003 server with :
    rdesktop -r disk:temp=/mnt/temp W2003
    2) go to this "temp" in "My Computer"
    3) Create this "long directory" (more than 127 char) :
    01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567
    4) You can't no more browse in the "temp" : you see the bug : you are disconnected !!

    Worst if this "long directory" is in a subdirectory, you are disconnected anyway !!

    Please correct this bug !

    Thanks for helps.

     
  • thoren007
    thoren007
    2009-03-09

    Hello !

    I'm the author of the comment "2008-12-03 14:43" :
    some news about this bug ???