Allow targetting specific file systems

[parshap]

Currently given strings are sanitized against all known file systems' requirements. It would be nice to allow the user to specify the file system they need to protect against.

See discussion in #9.

Different operating systems and different filesystems have different rules about what is a valid filename. We could let the user pass in a "target" system (e.g., "windows", or "fat32") and only sanitize against that system's rule.

That said, I think the default behavior should still be to sanitize against all systems. It seems like a safe default for users that don't bother to look at the options. It also handles the common use case of naming files that will be shared across systems (e.g., files served via http).

[joelmukuthu]

Hey @parshap, sorry for the prolonged silence. I wrote some tests for this and found it to be too complicated to even justify the feature. And since then I've wondered if anyone would actually need it as a feature. So I propose we close this issue and only re-open it if we get a request from someone.. what do you think?

[parshap]

No problem! But let's keep the issue open.

[joelmukuthu]

Cool :)

[mrchief]

Been over an year and no one has requested anything. Guess this can be closed now.

[parshap]

If this project was overwhelmed with open issues I'd close it, but I'll leave it open so it's visible and can be discussed it if anyone has ideas or use cases.

[paragi]

Hi
I started to use this nice and simple package.
But it seem to be a "windows only" package. I would have liked to know in advance.

Its far to restrictive for *nix systems, where almost all characters are legal and used in filenames (even wildcards and quotes)

It should IMO at least have a global option, or even better, check with os.platform()

Best regards
Simon Riget

[paragi]

You could add something like this:

if( os.platform() != 'win32' )
retun name.replace(//:null/g, '')

[parshap]

Hi @paragi. If you use os.platform() to determine how you sanitize you may be hurting users that are on a different platform than you. For example, an application running in a unix environment may want to be generating file names that are safe for use by Windows users.

I think an option for users to optionally specify what target systems to sanitize for (defaulting to all) would be great. Would you be interested in implementing that?

[paragi]

Hi @parshap
I understand your concern.
The real issue is that windows sanitizing is extremely complex, where as everyone else is simple.

Application are often meant for a specific purpose, on a specific platform. Therefore I subscribe to the view that; a library/module should default to support the platform its running on.
Windows file name restrictions would curb common filenames used on unix systems.

I would suggest something like this:

if( os.platform() != 'win32' )
        // in unix, only \x00 and path chars (/ .. ~) are illegal.
        return name.replace(/[\/\x00\~]/g, '').replace(/[.]{2,}/g, '');

Even wildcards pipe and quotes are legal. (if a little awkward at times :)

An option to sanitize more, and for windows compability, would of cause be nice :)

[parshap]

Yes, sanitizing for Windows is complex, but it already works well here. Changing this would be breaking for existing users and I think creating filenames that are safe for use across platforms is a common use case so we should continue to support that. I'm open to adding Unix-only sanitization as an option, but I am not open to changing the default behavior.

[paragi]

I respect that, and I thank you for a nice and easy to use tool, for windows filenames.

[mrchief]

It's not just OSes; one could use this package to sanitize filenames before storing in a database or before outputting on HTML pages. So I wouldn't tie this package up to file systems specifically.

Note: I'm aware of this package being node only, but given it's generic nature, this can easily be transformed into a UMD package. I would actually vote for that - make this isomorphic!

[parshap]

Indeed! This package already works in a browser context via Browserify, Webpack, etc. In fact we run real browsers tests in CI via Sauce Labs:

node-sanitize-filename/.travis.yml

Line 46 in 0d21bf1

npm run test-browser-sauce

See also #37.

[12people]

My use-case for FAT32 filenames is that it's still kind of the lowest common denominator in terms of OS support. As such, Linux distributions often default to FAT32 for formatting flash drives (NTFS is not supported by macOS and I believe there may be legal issues with exFAT).

As such, I would love to be able to produce filenames that are FAT32-compatible.