Re: fdatasync() error in shred from coreutils-5.2.1 on AIX 5.2

[Eli Zaretskii]

> From: Paul Eggert <address@hidden>
> Date: Tue, 18 May 2004 15:53:07 -0700
> 
> It creates a file name of the same length as the original, using
> letters from nameset.  E.g.:
> 
> foobar.txt
> 0000000000

Yes, I understood that much from the code, thanks.

> The former name is valid in an 8.3 system, but the latter isn't, so the
> rename will fail.

That's your mistake: it won't fail.  What you get is a file named
"00000000" (8 zeros), i.e. the OS silently truncates the name to the
8+3 limits.  Similarly, "123456789.1234" would be truncated to
"12345678.123" and the rename will succeed.

(This silent truncation is the main reason why GNU software, whose
source file names generally exceed the 8+3 limits, can at all be
built and used on 8+3 filesystems.)

What _would_ fail is if the new name is invalid on 8.3 filesystems
because it violates other limitations: uses characters that are not
allowed, as in "00000000+000" (`+' is not allowed), or has a leading
dot, as in ".00000", or has more than one dot, as in "00000.000.000".
And the correct reaction to such failures is not necessarily to
truncate the failing name, since the offending character could be the
first one.

> A similar argument applies to case-insensitive file systems.

Well, now that the former case has been dealt with, what ``similar
argument'' would that be? ;-)

Btw, Jim: shred.c use a literal comparison with '/' in file names
where it should use the ISSLASH macro instead.