Windows Filesystem is Broken
Roy Schestowitz
handling. Windows beyrays me constantly and I seek solutions and
justification/defence in the name of Windows.
First of all, on a Windows 98 laptop, I was able to copy a file with one
unicode character within. I am unable to delete it though; scandisk cannot
help either. In Windows 2000 (a different machine), I have a filename whose
path is deep (long) and, again, I am unable to erase it and this causes a
great deal of clutter.
More annoyingly, I virtually spent 3 days trying to make a backup from one
Windows machine to another. It turned out that transfer protocols do not
cater for paths exceeding a certain size (what the heck??). This never ever
happened on old distributions of Linux that I use.
Can anybody advise? Am I being harsh? Windows has cost me a lot of time, so
how can I not rant about it? The new Microsoft mantra is "It just works",
but quite frankly, it often doesn't.
Roy
--
Roy S. Schestowitz
http://Schestowitz.com
Marcus Houlden
wrote the following to uk.comp.os.win2000:
> Arguably, the most fundamental part of an operating system is file
> handling. Windows beyrays me constantly and I seek solutions and
> justification/defence in the name of Windows.
>
> First of all, on a Windows 98 laptop, I was able to copy a file with one
> unicode character within. I am unable to delete it though; scandisk cannot
> help either. In Windows 2000 (a different machine), I have a filename whose
> path is deep (long) and, again, I am unable to erase it and this causes a
> great deal of clutter.
Use the DOS or command prompt to sort both those out. For the first one,
open a DOS prompt in the directory where the offending file is (use CD to
get there) and use DEL with wildcards to delete the file, something like
DEL "unicode character*.*"
The first * should be just before the unicode character. Any file or
directory names containing spaces should be surrounded by quote marks,
especially on Win98.
For the second one, same again. Change to the directory using CD, one
directory at a time, and then DEL <filename> to get rid of the file. Move
back up the tree with CD .. and use RD <directory name> to get rid of the
directory (if that's what you want to do).
> More annoyingly, I virtually spent 3 days trying to make a backup from one
> Windows machine to another. It turned out that transfer protocols do not
> cater for paths exceeding a certain size (what the heck??). This never ever
> happened on old distributions of Linux that I use.
Create a share on the offending directory, so on the other machine it will
appear as SHARE_NAME on COMPUTER and copy across that way. Either that or
burn the files to CD or DVD.
mh.
--
Reply-to address *is* valid. "From" address is a blackhole.
This space to let.
Roy Schestowitz
> On Sun, 24 Apr 2005 00:49:37 +0100, Roy Schestowitz
> <newsg...@schestowitz.com> wrote the following to uk.comp.os.win2000:
>
>> Arguably, the most fundamental part of an operating system is file
>> handling. Windows beyrays me constantly and I seek solutions and
>> justification/defence in the name of Windows.
>>
>> First of all, on a Windows 98 laptop, I was able to copy a file with one
>> unicode character within. I am unable to delete it though; scandisk
>> cannot help either. In Windows 2000 (a different machine), I have a
>> filename whose path is deep (long) and, again, I am unable to erase it
>> and this causes a great deal of clutter.
>
> Use the DOS or command prompt to sort both those out. For the first one,
> open a DOS prompt in the directory where the offending file is (use CD to
> get there) and use DEL with wildcards to delete the file, something like
>
> DEL "unicode character*.*"
Good idea. I'll try that.
> The first * should be just before the unicode character. Any file or
> directory names containing spaces should be surrounded by quote marks,
> especially on Win98.
>
> For the second one, same again. Change to the directory using CD, one
> directory at a time, and then DEL <filename> to get rid of the file. Move
> back up the tree with CD .. and use RD <directory name> to get rid of the
> directory (if that's what you want to do).
Right again. I never thought DOS can handle something that the GUI cannot.
>> More annoyingly, I virtually spent 3 days trying to make a backup from
>> one Windows machine to another. It turned out that transfer protocols do
>> not cater for paths exceeding a certain size (what the heck??). This
>> never ever happened on old distributions of Linux that I use.
>
> Create a share on the offending directory, so on the other machine it will
> appear as SHARE_NAME on COMPUTER and copy across that way. Either that or
> burn the files to CD or DVD.
>
> mh.
Thanks for the help. All the solutions are hacks or work-arounds, which
proves to me that Windows is deficient.
Roy
UPDATE:
- Just tried the first tip... it did not work. Not only does Windows display
an odd filename, but it also 'thinks' it's a directory so wildcards won't
work.
- I haven't tried the second one yet.
- As for the third, I zipped up the 'long directories' shortly after writing
the original message. *sigh*
Jeff Gaines
> More annoyingly, I virtually spent 3 days trying to make a backup
> from one Windows machine to another. It turned out that transfer
> protocols do not cater for paths exceeding a certain size (what the
> heck??). This never ever happened on old distributions of Linux that
> I use.
>
> Can anybody advise? Am I being harsh? Windows has cost me a lot of
> time, so how can I not rant about it? The new Microsoft mantra is "It
> just works", but quite frankly, it often doesn't.
>
> Roy
MAX_PATH is defined in the Windows API as 256 and is the maximum length
of a full path to a file (including its name and extension).
It seems though that it is possible to create a file that exceeds this
limit, goodness knows how. A solution is to rename some of the
directories on the path to a single letter until you get back under the
limit - not something you want to do every day.
As you use Linux perhaps you could mount the offending drive under
Linux and sort it out?
--
Jeff Gaines
Posted with XanaNews 1.17.3.1
Roy Schestowitz
> On 24/04/2005 Roy Schestowitz wrote:
>
>> More annoyingly, I virtually spent 3 days trying to make a backup
>> from one Windows machine to another. It turned out that transfer
>> protocols do not cater for paths exceeding a certain size (what the
>> heck??). This never ever happened on old distributions of Linux that
>> I use.
>>
>> Can anybody advise? Am I being harsh? Windows has cost me a lot of
>> time, so how can I not rant about it? The new Microsoft mantra is "It
>> just works", but quite frankly, it often doesn't.
>>
>> Roy
>
>
> MAX_PATH is defined in the Windows API as 256 and is the maximum length
> of a full path to a file (including its name and extension).
Why isn't that common knowledge? And where is standardisation?
> It seems though that it is possible to create a file that exceeds this
> limit, goodness knows how. A solution is to rename some of the
> directories on the path to a single letter until you get back under the
> limit - not something you want to do every day.
Yes, but here is my problem... like you suggest, it's not something I want
to do every day.
Once every 2 weeks I back up 3+ GB of data by transferring from one
hard-drive to another. This requires several hours to complete and takes
place while I'm away. I can never know which new locations are 'too long'
and it might take hours until an error is flagged. If this occurs, I need
to retry the following day, which means another day without my laptop.
> As you use Linux perhaps you could mount the offending drive under
> Linux and sort it out?
I am actually waiting for my 5.5 year-old laptop to die so that I can buy a
different machine which is Windows-free. Honestly, no offence towards
Windows; it is just being a constant pain and yet so many people use it.
Jeff Gaines
> > MAX_PATH is defined in the Windows API as 256 and is the maximum
> > length of a full path to a file (including its name and extension).
>
> Why isn't that common knowledge? And where is standardisation?
Interesting, I have written apps for Windows so it's common knowledge
for me (and other developers I guess) but having poked about in Windows
help I can't find a reference to it!
> Yes, but here is my problem... like you suggest, it's not something I
> want to do every day.
>
> Once every 2 weeks I back up 3+ GB of data by transferring from one
> hard-drive to another. This requires several hours to complete and
> takes place while I'm away. I can never know which new locations are
> 'too long' and it might take hours until an error is flagged. If this
> occurs, I need to retry the following day, which means another day
> without my laptop.
The only thing I can think of is going through the source directories
and checking their length, a pain but you may have to do it once only?
> I am actually waiting for my 5.5 year-old laptop to die so that I can
> buy a different machine which is Windows-free. Honestly, no offence
> towards Windows; it is just being a constant pain and yet so many
> people use it.
Yes, MS is an excellent marketing organisation, I am sure they could
successfully get a Jewish Pope elected :-)
I have just ordered an iBook, if I get on with it I will probably
switch over to Mac machines from my Windows boxes.
thoss
<newsg...@schestowitz.com> writes
>Thanks for the help. All the solutions are hacks or work-arounds, which
>proves to me that Windows is deficient.
So what's new?
--
Thoss
Roy Schestowitz
Looking at my phrasing again, I should have added "yet again". The file
system is the very core of any operating system. Perhaps they should worry
about the basics before working on spherical desktop environment and come
out with statement like "It just works".
Roy
Peter Scales
<newsg...@schestowitz.com> writes
>Jeff Gaines wrote:
>
<snip>
>>
>> MAX_PATH is defined in the Windows API as 256 and is the maximum length
>> of a full path to a file (including its name and extension).
>
>Why isn't that common knowledge? And where is standardisation?
<snipped>
In the copy of the Microsoft Platform SDK that I have (August 2001),
MAX_PATH is defined as 260 (and in all the other versions that I can
remember seeing). It can be circumvented. This is what the Microsoft
Platform SDK (August 2001) says:
'The globally defined constant MAX_PATH defines the maximum number of
characters a path can have. You can avoid this constraint by doing both
of the following:
Referring to volumes by their unique volume names, which have \\?
prepended to the path.
Using Unicode so that you use the Unicode (W) versions of file
functions, which support the \\? prefix.
The \\?\ turns off path parsing. By using this form, you can work with
paths that are nearly 32,000 Unicode characters long. However, each
component in the path cannot be more than a file-system-specific value
indicated by the function GetVolumeInformation. You must use full paths
with this technique. This technique also works with universal naming
convention (UNC) names such as "\\OtherComputer\Directory\Filename.ext".
The \\?\ is ignored as part of the path example, and
"\\?\C:\myworld\private" is seen as "C:\myworld\private".'
It may not be common knowledge, but it is certainly freely available
knowledge. The latest Microsoft Platform SDK can be downloaded for free
(call charges might apply) from
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
There is a lot of good stuff available there. Alternatively, you can
search/browse the SDK online at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdkintro
/sdkintro/devdoc_platform_software_development_kit_start_page.asp
Regards
Pete
--
Peter Scales
Guy Harrison
> Arguably, the most fundamental part of an operating system is file
> handling. Windows beyrays me constantly and I seek solutions and
> justification/defence in the name of Windows.
>
> First of all, on a Windows 98 laptop, I was able to copy a file with one
> unicode character within. I am unable to delete it though; scandisk cannot
> help either. In Windows 2000 (a different machine), I have a filename
> whose path is deep (long) and, again, I am unable to erase it and this
> causes a great deal of clutter.
"dir /x" might help ("dir /?" for terse help). You ought to be able to
specify the shortname if one exists. IIRC that'll be the case for names
longer than 8+3 (DOS) and fingers crossed may apply for the (16bit) unicode
characters.
> More annoyingly, I virtually spent 3 days trying to make a backup from one
> Windows machine to another. It turned out that transfer protocols do not
> cater for paths exceeding a certain size (what the heck??). This never
> ever happened on old distributions of Linux that I use.
Peter covered this.
> Can anybody advise? Am I being harsh? Windows has cost me a lot of time,
> so how can I not rant about it? The new Microsoft mantra is "It just
> works", but quite frankly, it often doesn't.
If you've not heard of it... visit www.cygwin.com for a unix environment
under NT based systems. It's "package based" so via using their 'setup.exe'
you can choose to install as little or much as you like (even X). I dunno
if Win98 is still supported or not. It *may* be the case their (say) 'tar'
can deal with very long names. In any case you could cobble together a
script to shorten the names prior to tar then expand them afterward.
There's always knoppix. Personally I back up my windows partitions with 'dd'
though I dare say that's too low level here.
Roy Schestowitz
> Roy Schestowitz wrote:
>
>> Arguably, the most fundamental part of an operating system is file
>> handling. Windows beyrays me constantly and I seek solutions and
>> justification/defence in the name of Windows.
>>
>> First of all, on a Windows 98 laptop, I was able to copy a file with one
>> unicode character within. I am unable to delete it though; scandisk
>> cannot help either. In Windows 2000 (a different machine), I have a
>> filename whose path is deep (long) and, again, I am unable to erase it
>> and this causes a great deal of clutter.
>
> "dir /x" might help ("dir /?" for terse help). You ought to be able to
> specify the shortname if one exists. IIRC that'll be the case for names
> longer than 8+3 (DOS) and fingers crossed may apply for the (16bit)
> unicode characters.
I thought about doing this, but the operating system thinks the file is in
fact a directory. So, no way exists for treating that rotten element.
>> More annoyingly, I virtually spent 3 days trying to make a backup from
>> one Windows machine to another. It turned out that transfer protocols do
>> not cater for paths exceeding a certain size (what the heck??). This
>> never ever happened on old distributions of Linux that I use.
>
> Peter covered this.
>
>> Can anybody advise? Am I being harsh? Windows has cost me a lot of time,
>> so how can I not rant about it? The new Microsoft mantra is "It just
>> works", but quite frankly, it often doesn't.
>
> If you've not heard of it... visit www.cygwin.com for a unix environment
> under NT based systems. It's "package based" so via using their
> 'setup.exe' you can choose to install as little or much as you like (even
> X). I dunno if Win98 is still supported or not. It *may* be the case their
> (say) 'tar' can deal with very long names. In any case you could cobble
> together a script to shorten the names prior to tar then expand them
> afterward.
>
> There's always knoppix. Personally I back up my windows partitions with
> 'dd' though I dare say that's too low level here.
Thanks for that. I installed Cygwin in the past, but it was not of much use.
I only use my Windows 98 laptop for storage (mobile storage), but as I need
back-ups of that storage, it is only pathname length that bothered me.
Compressing branches as I did to resolve the problem is not ideal. This
will ruin indexing of my data in the future, which is what I sought a
workaround.