RE: [Gnu-arch-users] tla1.2 on cygwin

[David A. Wheeler]

address@hidden said:

> Path Compression is independent of cygwin, and of NTFS.
> 
> tla compiles without modification on cygwin, so no need to port it.
> 
> (Johannes Berg is porting tla/hackerlab to win32, which is a major
> undertaking.

And HOORAY.  I think this is a very important task.


> The only problem for using it on FAT is that tla depends on "inode"
> values, and FAT does not have them, NTFS does have a similar thing.

If you're accessing a FAT system from say a Linux system,
Linux _does_ create inode numbers for a FAT system.
How does it create those?  Does it use locations on the disk
to create them?  If so, could the same approach be used to
determine inode numbers (by doing a little mucking)?

Alternatively - can tla back off to a slower/more painful method
when inode numbers aren't available?
I didn't see in a search a discussion of WHY & WHEN arch depends so
strongly on inode numbers; can someone BRIEFLY explain this?


> To clarify for all: NTFS does support path lengths to 32000 chars, but
> there's a catch.
> 
> On Windows, for each function, there is an ANSI version, and a Unicode
> version. For example:
> CreateFileA(char* path) and CreateFileW(w_char* path)
> If one uses the CreateFileW() function, and the path starts with "\\?\"
> then the path can be 32000 chars. If the path starts with something else
> it is limited to 250 chars.
> 
> So most programs (being unaware of this) do not support long path names,
> ("most programs" include cmd.exe, explorer.exe, notepad.exe, gnuemacs.exe,
> ...)

Ugh.  Still, a Windows port could at least use long names
internally for the stuff under {arch}, archives, etc.  But would that
work for older systems?  Are CreateFileW() avaialable, in, say,
Windows 98?


> >The one caveat may be that filepermission metadata might be
> >fully handled.  I know Cygwin on NT/2000/XP can use extended
> >attributes on FAT to support permissions, but this still does not
> >address the 9x/ME systems.
> >In this case my preference would be to disallow permissions
> >changes based upon the apparent permissions on these platforms.

That's probably the best course, at least for the moment.
You could create a "tla chmod" command, that stored
up permissions to be changed, so that you could change permissions
even in those cases.  tla chmod could work on any system,
though it'd only be needed in those cases.


--- David A. Wheeler <address@hidden>