Limiting file/folder name length and file size

Hello,
Is there a way in Teamsite to restrict the length of filname and foldername? The files could be generated from DCTs or directly imported from the local machine.
While deploying, I'm writing the filename in the database, so I must have a max limit to it.
I know I can do it by having a validate task and then checking the length there, but then the user will get an error only while submitting.

Another question.
Is it possible to limit file size of certain file types while doing a file import? i.e. do not let the users import images that are more than 1MB etc.

TIA
-Ashish

Find more posts tagged with

Comments

Adam Stoller

All is possible - but not something which is configurable out-of-the-box. I.e. if you replace standard OOTB menu items with custom menu items calling your own custom scripts - those custom scripts can restrict the length of filenames and/or directory names, and could do initial checks before performing file importing. You can also use FormAPI within TeamSite Templating to pre-validate filenames for DCRs and use automated processes for generating pages from DCRs to gain control over the names of generated pages.

All of this will allow you to do what you are asking - when used from the browser interface. However, all of this can be circumvented if you (or your users) come in through the file system interface.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

bboyle

what about using a command trigger (i.e iwatcreate)?

I'd like some more control over filenames. We've had one incident with an author naming a file like "this&that" ... the "&" caused problems in the job spec XML because it hadn't been converted to an entity. Naturally we'll touch up our workflow template, but ideally we do not want people using the "&" character in their filenames. Nor spaces.

I have not tried command triggers and am a little uncertain. How have others found them? Any issues with the performance hit the system takes running a script every time an event is triggered?

thanks
Ben

Migrateduser

The command triggers are just that, "triggers". They are useful if you may want to kick-off some processing under certain conditions. But -- for performance reasons -- they are not event handlers. You cannot use them to intercept and possibly reject an action.

In other words, you could try to use a trigger to detect an invalid pathname and start some "corrective" action, like renaming the file (but to what?) or sending a notification to some user. But you can't use them prevent an invalid pathname. To trap the attempt before the operation occurs you would need to modify the UI.

Brinko Kobrin
Interwoven Staff Engineer

Adam Stoller

As brinko indicated - triggers are POST-operative - i.e. the action has already taken place and you could then perform "corrective" procedures. And as he also pointed out - there's a peformance hit for triggers because they will fire off everytime the action occurs (in this case, that *might* be a wash with creating your own custom menus to replace OOTB menus, but ..)

Ideally, I think, it would be nice to open a feature request for something like an iw.cfg directive:

    file_entry_illegal_chars="`~!@$^&amp;*(){}[]\\|;<>?/\"'\s\t"

And have all the UI (GUI, file system interface, OpenAPI, CSSDK) functions that deal with file and/or directory creation trap requests to create file and/or directory names that contain such characters to reject the request with a meaningful error message:

ERROR: Unable to create file entry (this&that), contains one or more
       configured illegal characters: "`~!@$^&amp;*(){}[]\\|;<>?/\"'\s\t"

I know of many cases where such a configuration option would eliminate a bunch of customizations that have had to been made at customer sites.

Brinko - can you see about filing this?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

bboyle

Yes a configurable list of "illegal characters" would solve this for us. I'll send it to support to make it "official".

bboyle

Thanks for the extra info, appreciate it.

But how many places in the UI are there to trap?
- Templated files can be managed with FormAPI
Then there are the menus ...
- new file
- new directory
- import files (yikes, how would we customise this one?)
- copy
- move
- rename

We don't have to worry about mapped drives, front office, etc in our implementation (at least, not yet). Still, that's a lot of customisation. That's why I was leaning towards a trigger.

There's also the human aspect. Training our users and rejecting files (in the workflow) that don't match our criteria. I'm liking the sound of that ...
Smiley Happy

skbaker

I am also in need of a way to ensure that when users generate HTML files, the file names do not contain any invalid characters (space, &, etc).

I'm excited to see that this will be added as a feature request. In the meantime, can anyone help me solve my problem?

We are so far able to capture the generate event within the TPL, and we can use perl within the TPL to review the user-entered filename for validity. The problem we have is that if the filename is not valid, and we error out of the TPL, then the file is still created (although empty) on the server. Is there any way to avoid this? I don't want empty files on the server, because they could get deployed.

I'd appreciate any advice anyone has. We're running TS 5.5.2 on AIX.

Migrateduser

fish~

I have entered this feature request, identified as 51395. Thanks for the suggestion.

Brinko Kobrin
Interwoven Staff Engineer

Adam Stoller

The only way to currently control the naming of generated files, as far as I know, is to drive most of the process via workflow and disable (as much as possible) the Generate options from TeamSite / TeamSite Templating.

The customer I currently work for has a workflow for creating files - in which a few prompts up front determine the category and data-type, and then there's a cgitask script used to determine the "selected path" and filename of the DCR (the "selected path" being the path under AREA/.../data/ where the DCR will be created and which also will be used directly under AREA/ for the output file(s) -- in most cases, the output files are the name of the dcr with ".html" slapped on the end)

By controlling the naming of the dcr's and the location where the dcrs are stored and then using a convention for generating the files - as long as you control the directory and file naming of the DCR - everything else is taken care of. In this case, the directories are pre-existing and I believe can only be created by administrators; and the filenames are checked for bad characters within the cgi script.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com