gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] How to support arch on systems with a small PATH_MA


From: chth
Subject: Re: [Gnu-arch-users] How to support arch on systems with a small PATH_MAX [WAS: arch o n windows?]
Date: Thu, 15 Jul 2004 08:00:38 +0200

Hi James,

> > usage: tla fslint [archive|directory] filesystems...
> >  
> > (assume there is a 'foo:bar.barf' file in the archive)
> > $ tla fslint address@hidden/hello--unix--0,1 fat16 
> > foo:bar.barf foo_bar.bar  /* [fat16] illegal character ':',
> > extension to long */
> 
> I think like this idea. Nothwithstanding, there's a _lot_ of
> filesystems out there. 
> 
> I'd also like to see a default in fslint that checks against all known
> filesystem types.
> 
> Do you plan for fslint to be able to catch pairs of files that are
> valid on one filesystem "This and This" that won't work on case
> insensitive filesystems? 

That all needs to be worked out, ideas (note: some are redundant but
give finer grained possibilities for error messages):
 - full pathname length check
 - length check for each dirname
 - filename length check
 - dir nesting depth check
 - regex against full pathname
 - regex against each directory
 - regex against filename
 - case preserving check (will filenames be altered?)
 - case significance check (will filenames become new identifiers?)
 - filename collision check (will the fs treat filenames as the same)
 - charset checks (is the charset supported/will it look weird)

then generation of acceptable alternatives and ensure that generated
filenames dont collide (note: M$ has an offical KB article for FAT
filesystem stuff about their (re-)naming rules, afaik there is similar
for iso9660)

Note: there are 2 possible cases for fslint checks:
 1) will this archive/tree work on some other filesystem
 2) will that archive/tree work here on my filesystem
there are subtle differences like in case 1) it can't determined if the
final pathlength is always between its bounds because the user might put
it anywhere.

> > the filename should be escaped using pika rules
> > next this output can be used in a {arch}/aliases file where tla maps
> > filenames as:
> 
> Can you show a couple examples? I haven't seen pika rules yet 

$ echo $(tla escape 'foo bar')
foo\(sp)bar


> 
> > Note: such a fslint could be done as external tool too and does not
> > need to be integrated into tla.
> >
> 
> I'd like to think that some day portability will become a higher
> priority. In that spirit, I'd like to see fslint integrated. 

Ack, its just an option to do it as external tool.


> And while you're at it, I'd actually rather see fslint do *more*. For
> example, I'd like to see a fslint check against every file that gets
> added in tla. In other words:
 
I rather favour expensive testing which might degrade performance.
People might still put fslint into their hooks. It should be optional at
least. Many projects don't require a big deal of filesystem portability
and making such checks buildin will require additional metadata
describing the target filesystems. I don't think thats required and it
will be the far more common case that someone else who checks out an
archive will need to check agianst his local filesystem.

Doing a mandatory fslint on 'tla get' would be an option if you can tell
me how tla can determine the filesystem where it puts the data in a
portable way. (would be fun to write a filename stress test suite to
fingerprint unknown filesystems, but that also to expensive on 'tla
get')


        Christian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]