Re: Issues removing files with certain characters in their names.

[Rich Felker]

On Fri, May 30, 2014 at 09:18:19PM +0200, Harald Becker wrote:
> Hi Rich !
> 
> >My statement was imprecise; of course to support users still
> >stuck on legacy locales, nl_langinfo(CODESET) should be
> >consulted.
> 
> How do you determine the correct code set of a foreign file
> system on an external drive? How can you tell if all systems
> which accessed this drive has handled translations in the correct
> way?

All modern filesystems used on external devices (fat32, ntfs, udf,
...) use Unicode-based encodings for filenames, so the foreign
encoding is known and fixed.

> >>  and not only unzip may produce such results. Think of
> >> using an USB stick at an Windows machine, then carry that over
> >> to an Linux machine.
> >
> >The filenames are stored in UCS-2. No problem.
> 
> UCS-2 with different code page translations from an 8 bit
> charset. Translations which leave name mapping in inconsistent
> state when further translations occur.

I don't follow what you think the problem is.

> >If you mount it incorrectly, then this is user error.
> 
> Correct, all those trouble arrives due to anybody having an
> incorrect setup. This will ripple trough and may produce trouble
> on other ends.

All modern Linux-based systems use the utf8 option by default when
mounting filesystems that don't store filenames as pure byte strings
but in a Unicode-based form. You have to be rolling your own or else
actively breaking your system's default setup to get this wrong.

> >All programs are not affected. Only programs which read
> >filenames as byte strings from foreign sources (such as the
> >directory table of a zip file) are affected.
> 
>  but how do you know the code page the zip archive uses. How
> do you know you need to do translations? I'm unsure if the archiv
> contains this information, so it needs to be provided by a much
> more error prone user.

When encountering such an archive, the unzip utility could simply exit
with an error when there are non-ASCII names unless the user specifies
the encoding. To be less error-prone, it could print the names as
interpreted in several different encodings as part of the error
message, to help the user identify which one is correct. IMO it should
also automatically assume UTF-8 and suppress the error condition if
the names all decode as valid UTF-8, since the probability of
meaningful non-UTF-8 text decoding successful as UTF-8 is negligible.

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Ralf Friedl]

Jason Cipriani wrote:

I just want to bring to attention a potential issue, described here:

http://superuser.com/questions/587778/cant-delete-file-with-foreign-letters

It seems at least two users (the original poster and also this post 
) were unable to remove a file 
that contained certain foreign characters in the filename, both using 
BusyBox.


In one case a user resorted to setting up a samba server then deleting 
the file remotely from Windows. In the other case the discovered 
workaround was to "rm -i *" and answer no to all files except the 
problematic one.


Not sure if this is BusyBox-specific issue, user error, or something 
else, and I don't have BusyBox to test, but I thought it was 
significant that both users with that problem were using it and am 
reporting it here in case anybody is interested in investigating.


This issue has nothing to do with busybox, it is related to the kernel 
and to non Linux file systems. A Linux file system should be able to use 
anything as the filename that doesn't exceed the length for a file entry 
and doesn't contain '/' or '\0'. It should provide back the exactly the 
same string with readdir. The kernel also make no assumption about an 
encoding of the file names.


When accessing other file systems, especially FAT and NTFS, this is not 
true, but it is not a problem busybox can solve. The kernel should be 
able to access and delete the files it has created on such a file system 
with the same settings, but there is no guarantee that the files on such 
a file system have been created with the same settings, of even by a 
Linux kernel. In the case of NTFS, it is now common to use the userspace 
NTFS file system, so it is not really a kernel issue.


Files are stored as UCS-2 on NTFS and VFAT but not on regular FAT file 
systems. In this case NTFS is mentioned, but no information on mount 
options and in general not enough information to reproduce the problem.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Harald Becker]

Hi Rich !

>My statement was imprecise; of course to support users still
>stuck on legacy locales, nl_langinfo(CODESET) should be
>consulted.

How do you determine the correct code set of a foreign file
system on an external drive? How can you tell if all systems
which accessed this drive has handled translations in the correct
way?

>>  and not only unzip may produce such results. Think of
>> using an USB stick at an Windows machine, then carry that over
>> to an Linux machine.
>
>The filenames are stored in UCS-2. No problem.

UCS-2 with different code page translations from an 8 bit
charset. Translations which leave name mapping in inconsistent
state when further translations occur.

>If you mount it incorrectly, then this is user error.

Correct, all those trouble arrives due to anybody having an
incorrect setup. This will ripple trough and may produce trouble
on other ends.

>All programs are not affected. Only programs which read
>filenames as byte strings from foreign sources (such as the
>directory table of a zip file) are affected.

... but how do you know the code page the zip archive uses. How
do you know you need to do translations? I'm unsure if the archiv
contains this information, so it needs to be provided by a much
more error prone user.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Harald Becker]

Hi Rich !

[To Rich: I have permanent mail failures on dal...@libc.org:
domain has no valid mail exchangers, answer is from GMX mail
server]


On 30-05-2014 14:12 Rich Felker  wrote:

>ls never performas any filtering.

Sorry, yes. The name filtering is in the glob, not ls. My
mistake. So ls just displays the names from readdir. Beside that
mistake with filtering it's as I told.

>Printability has nothing to do with processing the filename. And
>a zero byte fundamentally cannot be in a filename (the filename
>in the directory table consists of those characters up to, and
>not including, any zero byte stored).

This is true on a Unix system, but have you looked what Windows
system do? Mapping of names is from to charset code pages is done
in so different ways, many of such mappings may produce unusual
characters. Those unusual characters can produce unusual
effects in further translations, ending up in illegal names when
translated to Unix file names.

With UTF-8 this is all getting better, but before name mangling
of foreign characters was a hell.


... you called it a user error when mounted incorrect. Yes, using
foreign characters in file names is the worst user error. All the
mentioned problems happen after a combination of translation
between different charsets. It is not a single point of failure
producing those problems. The chain of translations lead
sometimes to situations where file names from readdir let stat
fail with same name. All other name confusion can easily be
solved with pattern usage, but when stat fail with names from
readdir you are in trouble. Again, it should not happen, but it
happens - so call it shit.

And remember: All those translations are part of file system
drivers, not part of user space software. Most such userspace
software just passes names just straight through, without
modifications. So tell, who made the error?

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Rich Felker]

On Fri, May 30, 2014 at 08:06:24PM +0200, Harald Becker wrote:
> Hi Joshua !
> 
> On 29-05-2014 18:41 Joshua Judson Rosen 
> wrote:
> 
> >But why is ls able to match the files when rm is not able to
> >remove them?
> 
> The problem happens on the opposite direction you expect. It is
> not the create/open/unlink which modify the file name it is the
> directory scan. ls doesn't really match the filename. It just
> scans the directory, filters with given file name masks, then
> display what it got.

ls never performas any filtering. If ls is given a directory name, it
just reads the entries with readdir(); no 'matching' needs to take
place at all. If it's given a glob pattern, that glob never reaches
ls; it's expanded by the shell. If you quote the glob to actually pass
it to ls, ls will not process it as a glob pattern; it's treated as a
literal filename containing *'s or ?'s. So I don't understand what
you're claiming happens.

> But on some unusual file names the directory
> scan gives names which does not exactly match the name stored on
> file system. They can be displayed, but used for an remove or
> move operation the stat/unlink fails. This usually happens
> when the names contain control or unprintable characters
> (e.g. a byte with all zero) which get removed by the
> kernel/file system driver.

Printability has nothing to do with processing the filename. And a
zero byte fundamentally cannot be in a filename (the filename in the
directory table consists of those characters up to, and not including,
any zero byte stored).

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Harald Becker]

Hi Joshua !

On 29-05-2014 18:41 Joshua Judson Rosen 
wrote:

>But why is ls able to match the files when rm is not able to
>remove them?

The problem happens on the opposite direction you expect. It is
not the create/open/unlink which modify the file name it is the
directory scan. ls doesn't really match the filename. It just
scans the directory, filters with given file name masks, then
display what it got. But on some unusual file names the directory
scan gives names which does not exactly match the name stored on
file system. They can be displayed, but used for an remove or
move operation the stat/unlink fails. This usually happens
when the names contain control or unprintable characters
(e.g. a byte with all zero) which get removed by the
kernel/file system driver.

>Is it perhaps because ls is not actually doing any operations on
>the files themselves (not even a stat?), and just reporting the
>dirent->d_name strings that it got from readdir()? In which case
>"ls -l *" would fail on the same files even when "ls *" doesn't?

Correct.

>Or is there something deeper whereby stat() succeeds but
>unlink() fails?

No. Never got this.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Rich Felker]

On Thu, May 29, 2014 at 06:41:17PM -0400, Joshua Judson Rosen wrote:
> But why is ls able to match the files when rm is not able to remove them?

I have no idea. Have you tried running them under strace and seeing
where the failure occurs?

> Is it perhaps because ls is not actually doing any operations on the files
> themselves (not even a stat?), and just reporting the dirent->d_name strings
> that it got from readdir()? In which case "ls -l *" would fail on the same
> files even when "ls *" doesn't?

I doubt it.

> Or is there something deeper whereby stat() succeeds but unlink() fails?

I'm guessing it's a failure at in the userspace code for rm, not the
syscall. Again strace could help you confirm this and possibly
determine where rm's idea of the filename is getting corrupted.

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Joshua Judson Rosen]

But why is ls able to match the files when rm is not able to remove them?

Is it perhaps because ls is not actually doing any operations on the files
themselves (not even a stat?), and just reporting the dirent->d_name strings
that it got from readdir()? In which case "ls -l *" would fail on the same
files even when "ls *" doesn't?

Or is there something deeper whereby stat() succeeds but unlink() fails?

On 2014-05-29 18:32, Rich Felker wrote:

On Thu, May 29, 2014 at 11:27:07PM +0200, Harald Becker wrote:

Hi Rich !


I know this problem very well. It happens about every few
month, that I get a ZIP packaged file from a Windows system.
As the maintainer is a bit stupid, he can't manage to avoid
foreign characters and I end up with unusual file names after
unzip.


This sounds like a bug in the unzip utility. If it encounters
byte sequences which are not UTF-8, it should convert them from
whatever legacy encoding they're in to UTF-8, possibly issuing
an error that the user needs to specify this encoding if it
can't be determined.


Then you need to consider all programs buggy which don't
mangle with the file names. There are so many programs which just
copy filenames through and let the kernel decide what to do. And
I do not mean BB unzip here, normally I'm using the upstream
unzip.

 and how can you consider all names being UTF-8 ... nowadays
may be, but what when using 8 bit locales with different
charsets? UTF-8 mangling would be wrong on those.


My statement was imprecise; of course to support users still stuck on
legacy locales, nl_langinfo(CODESET) should be consulted.


 and not only unzip may produce such results. Think of using
an USB stick at an Windows machine, then carry that over to an
Linux machine.


The filenames are stored in UCS-2. No problem.


Depending on how the file system is mounted you
may get unusual file names when copying names with foreign
characters. Now who is bad?


If you mount it incorrectly, then this is user error. Note that
correct versus incorrect does not depend on the contents of the
storage device, only the encoding the local system where you're
mounting it is using.


Would be nice to have them all fixed ... get them all fixed the
same way when doing some mapping ... but can that ever reach all
programs? This is a so long standing problem, nobody really
cares.


All programs are not affected. Only programs which read filenames as
byte strings from foreign sources (such as the directory table of a
zip file) are affected.

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox



--
"'tis an ill wind that blows no minds."
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Rich Felker]

On Thu, May 29, 2014 at 11:27:07PM +0200, Harald Becker wrote:
> Hi Rich !
> 
> >> I know this problem very well. It happens about every few
> >> month, that I get a ZIP packaged file from a Windows system.
> >> As the maintainer is a bit stupid, he can't manage to avoid
> >> foreign characters and I end up with unusual file names after
> >> unzip.
> >
> >This sounds like a bug in the unzip utility. If it encounters
> >byte sequences which are not UTF-8, it should convert them from
> >whatever legacy encoding they're in to UTF-8, possibly issuing
> >an error that the user needs to specify this encoding if it
> >can't be determined.
> 
> Then you need to consider all programs buggy which don't
> mangle with the file names. There are so many programs which just
> copy filenames through and let the kernel decide what to do. And
> I do not mean BB unzip here, normally I'm using the upstream
> unzip.
> 
>  and how can you consider all names being UTF-8 ... nowadays
> may be, but what when using 8 bit locales with different
> charsets? UTF-8 mangling would be wrong on those.

My statement was imprecise; of course to support users still stuck on
legacy locales, nl_langinfo(CODESET) should be consulted.

>  and not only unzip may produce such results. Think of using
> an USB stick at an Windows machine, then carry that over to an
> Linux machine.

The filenames are stored in UCS-2. No problem.

> Depending on how the file system is mounted you
> may get unusual file names when copying names with foreign
> characters. Now who is bad?

If you mount it incorrectly, then this is user error. Note that
correct versus incorrect does not depend on the contents of the
storage device, only the encoding the local system where you're
mounting it is using.

> Would be nice to have them all fixed ... get them all fixed the
> same way when doing some mapping ... but can that ever reach all
> programs? This is a so long standing problem, nobody really
> cares. 

All programs are not affected. Only programs which read filenames as
byte strings from foreign sources (such as the directory table of a
zip file) are affected.

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Harald Becker]

Hi Rich !

>> I know this problem very well. It happens about every few
>> month, that I get a ZIP packaged file from a Windows system.
>> As the maintainer is a bit stupid, he can't manage to avoid
>> foreign characters and I end up with unusual file names after
>> unzip.
>
>This sounds like a bug in the unzip utility. If it encounters
>byte sequences which are not UTF-8, it should convert them from
>whatever legacy encoding they're in to UTF-8, possibly issuing
>an error that the user needs to specify this encoding if it
>can't be determined.

Then you need to consider all programs buggy which don't
mangle with the file names. There are so many programs which just
copy filenames through and let the kernel decide what to do. And
I do not mean BB unzip here, normally I'm using the upstream
unzip.

... and how can you consider all names being UTF-8 ... nowadays
may be, but what when using 8 bit locales with different
charsets? UTF-8 mangling would be wrong on those.

... and not only unzip may produce such results. Think of using
an USB stick at an Windows machine, then carry that over to an
Linux machine. Depending on how the file system is mounted you
may get unusual file names when copying names with foreign
characters. Now who is bad?

Would be nice to have them all fixed ... get them all fixed the
same way when doing some mapping ... but can that ever reach all
programs? This is a so long standing problem, nobody really
cares. 

>
>Rich


--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Rich Felker]

On Thu, May 29, 2014 at 09:18:26AM +0200, Harald Becker wrote:
> Hi Denys !
> 
> >> For what it's worth the users with this problem were unable to
> >> remove the files using wildcards. For example, one user had a
> >> file named:
> >>
> >>   På hjul.mkv
> >>
> >> ls P* displayed the file.
> >> rm P* returned the error "can't remove 'På Hjul.mkv': No such
> >> file or directory"
> >
> >I have hard time believing this.
> >Wildcard expansion is done by the shell, not by ls and rm.
> >
> >IOW: ls and rm see exactly the same expanded names.
> >
> >Since they don't mangle the names in any way
> >(e.g. no UTF-8 decoding) before feeding them to system calls,
> >it should work.
> 
> I know this problem very well. It happens about every few month,
> that I get a ZIP packaged file from a Windows system. As the
> maintainer is a bit stupid, he can't manage to avoid foreign
> characters and I end up with unusual file names after unzip.

This sounds like a bug in the unzip utility. If it encounters byte
sequences which are not UTF-8, it should convert them from whatever
legacy encoding they're in to UTF-8, possibly issuing an error that
the user needs to specify this encoding if it can't be determined.

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Harald Becker]

Hi Denys !

>> For what it's worth the users with this problem were unable to
>> remove the files using wildcards. For example, one user had a
>> file named:
>>
>>   På hjul.mkv
>>
>> ls P* displayed the file.
>> rm P* returned the error "can't remove 'På Hjul.mkv': No such
>> file or directory"
>
>I have hard time believing this.
>Wildcard expansion is done by the shell, not by ls and rm.
>
>IOW: ls and rm see exactly the same expanded names.
>
>Since they don't mangle the names in any way
>(e.g. no UTF-8 decoding) before feeding them to system calls,
>it should work.

I know this problem very well. It happens about every few month,
that I get a ZIP packaged file from a Windows system. As the
maintainer is a bit stupid, he can't manage to avoid foreign
characters and I end up with unusual file names after unzip.

Most likely they can be handled with wildcards (especially ?), but
sometimes it gets a bit tricky to access those files, as they
contain control or unprintable characters. In that case you need
to know the exact length and position to enter question marks in
file name.

If you do a rm -i * it fails. Not due to name mangling in
Busybox, but due to name mangling in file system drivers of the
kernel (especially on fat file systems - like USB sticks or flash
based disks).

Therefore this is not a Busybox related problem, it's a general
name handling problem when intermixing file systems and different
charsets / code pages. It does not depend on a special Busybox
version, I had the same problem even 10 years ago (complete
different versions of kernel/lib/programs).

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Denys Vlasenko]

On Wed, May 28, 2014 at 3:17 AM, Jason Cipriani
 wrote:
> For what it's worth the users with this problem were unable to remove the
> files using wildcards. For example, one user had a file named:
>
>   På hjul.mkv
>
> ls P* displayed the file.
> rm P* returned the error "can't remove 'På Hjul.mkv': No such file or
> directory"

I have hard time believing this.
Wildcard expansion is done by the shell, not by ls and rm.

IOW: ls and rm see exactly the same expanded names.

Since they don't mangle the names in any way
(e.g. no UTF-8 decoding) before feeding them to system calls,
it should work.

And it does work for me with current git. I just tested it.

What version of busybox is it and what is the .config?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[walter harms]

Am 28.05.2014 03:17, schrieb Jason Cipriani:
> On Tue, May 27, 2014 at 8:59 PM, Harald Becker  wrote:
> 
>>
>>> It seems at least two users ...
>>> were unable to remove a file that contained certain foreign
>>> characters in the filename, both using BusyBox.
>>
>> If files get saved with foreign characters you may have
>> trouble to enter those names on the command line, but you are
>> always able to replace such characters with shell pattern
>> characters (either ? or *). Just enter enough other characters to
>> select right file and use correct number of question marks to
>> replace the foreign characters or use shell star option(s) if
>> you can't determine correct number of characters which need to be
>> replaced.
> 
> 
> For what it's worth the users with this problem were unable to remove the
> files using wildcards. For example, one user had a file named:
> 
>   På hjul.mkv
> 
> ls P* displayed the file.
> rm P* returned the error "can't remove 'På Hjul.mkv': No such file or
> directory"
> 
> I have been unable to find other reports of problems like this. Perhaps it
> is unlucky that BusyBox just happened to be 2 for 2!
> 

 the gnu ls version has some special options to handel special characters,
 like -q/-Q/-b. Since this is not the normal case bb - as minimal version -
 does not support this. If you want to find what is going on; i send the
 output truh od (or xxd) and see everything as hexdump.

 re,
 wh
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Harald Becker]

Hi Jason !

>For what it's worth the users with this problem were unable to
>remove the files using wildcards. 

This most likely happen for the star operator. Use correct number
of question marks at correct position. This gives better results.

> For example, one user had a
>file named:
>
>  På hjul.mkv
>
>ls P* displayed the file.
>rm P* returned the error "can't remove 'På Hjul.mkv': No such
>file or directory"

Yes this happens if rm does a directory scan then does some
editing of the file name before using it. The biggest problem
here is, when the name contains characters that can't be
displayed or are used as control characters.

may be a
  find -name PATTERN -delete
helps or a
  find -name PATTERN -print0 | xargs -0 rm

>I have been unable to find other reports of problems like this.
>Perhaps it is unlucky that BusyBox just happened to be 2 for 2!

This is a well known problem which exists since there where
different code pages and character sets for different national
characters used to create file names on different file systems.
Those files are either created from other systems (may be using
samba) or are the result of untar/unzip/unrar of files packed on
Windows systems ... and there exist a few characters which get
really problematic when they get entered into file names, but
that's the mess with different code pages and file systems.

Since we have wide spread UTF-8 things seam to get better, but
still such shit happens (saying this, just got trouble after
unpacking a Zip-File, looks like it was packaged under Windows,
now I have files with none readable characters in my directory,
nothing has to do with busybox).

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Jason Cipriani]

On Tue, May 27, 2014 at 8:59 PM, Harald Becker  wrote:

>
> >It seems at least two users ...
> >were unable to remove a file that contained certain foreign
> >characters in the filename, both using BusyBox.
>
> If files get saved with foreign characters you may have
> trouble to enter those names on the command line, but you are
> always able to replace such characters with shell pattern
> characters (either ? or *). Just enter enough other characters to
> select right file and use correct number of question marks to
> replace the foreign characters or use shell star option(s) if
> you can't determine correct number of characters which need to be
> replaced.


For what it's worth the users with this problem were unable to remove the
files using wildcards. For example, one user had a file named:

  På hjul.mkv

ls P* displayed the file.
rm P* returned the error "can't remove 'På Hjul.mkv': No such file or
directory"

I have been unable to find other reports of problems like this. Perhaps it
is unlucky that BusyBox just happened to be 2 for 2!

Jason
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Issues removing files with certain characters in their names.

[Harald Becker]

Hi Jason !

>It seems at least two users ...
>were unable to remove a file that contained certain foreign
>characters in the filename, both using BusyBox.

This may only happen, when you access your file system using a
system using different language/charset definitions (e.g.
Windows). If files get saved with foreign characters you may have
trouble to enter those names on the command line, but you are
always able to replace such characters with shell pattern
characters (either ? or *). Just enter enough other characters to
select right file and use correct number of question marks to
replace the foreign characters or use shell star option(s) if
you can't determine correct number of characters which need to be
replaced.

In case you need to find out the full name of such files it can
help to use find to locate the file (find -name PATTERN) and save
the find result in a file. Then delete lines with names of files
you are not interested in. Then use xargs commands to work at
selected files (e.g. cat FILE_WITH_NAMES|xargs rm -i).

This is a general Unix shell related problem, not a Busybox
related topic. The only difference may be, that other shells than
Busybox ash may filter input on different foreign language
characters, so there may be difference in line editing/handling.
Placing the file names in an xargs command or using scripts
allows to bypass line edit filtering and may help accessing such
files.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox