Mail Archives: djgpp-workers/2001/09/23/22:28:08
The problem only happens when the short name length equivalent (w/o drive)
of the directory exceeds 64 characters (even when using lfn functions).
Wrote a simple test program to chdir to args on command line, printing
return codes and results from getcwd at each step. Two args:
.libs/libstdc++.lax ..
Using long names:
can cd to the directory (no failure). If the short name equivalent
of the directory is > 64 characters, getcwd returns d:\
What is more interesting is from that point if I change directory a
second time to .. (in the same image) - it changes to the correct
directory and prints the correct name. So the problem seems to be
completely with getcwd in the test (I'm guessing that findfirst
internally hits the same buggy problem inside Win2K?)
Using short names (lfn=n):
can cd to the directory (but returns failure ENOENT) - but that directory
is actually current. getcwd returns the name truncated to 64-characters
(a partial part of the name on the last name displayed). Second change
dir to .. works just fine as above.
ls can see all the files in directories - so this seems to be a current
working directory limitation (if you don't change directory not a problem).
Now, if I use the LFN TSR - I get a chdir failed message, I get a getcwd
failed message (but my current directory did actually change!) and the
second change to .. works. So running with the TSR actually causes rm -ir
to see an error and fail. (It does leave you in the nested directory
however, with the short name in my prompt being the truncated value...).
So to protect your files, run with the LFN TSR (which prevents you from
going too deep).
I'll have to look and see if we can add some protection for this.
- Raw text -