search

joyent / libuv

Go to
https://github.com/libuv/libuv
3.27k stars 654 forks source link

SetFileAttributes (attrib) binding #406

Closed piscisaureus closed 9 years ago

piscisaureus commented 12 years ago

I am considering adding a binding for [http://msdn.microsoft.com/en-us/library/windows/desktop/aa365535%28v=vs.85%29.aspx].

That would allow users to specify file attributes, such as, making .node_history actually invisible.

On unix the it could just ignore the attributes that are not supported. (I think setting the "readonly" bit could chmod the file, taking away all the write bits).

(On a side note, I think libuv should fail with ENOSYS when the user tries to chown a file. The user probably does this for security purposes, so making it a no-op on windows is a bit risky).

@bnoordhuis @isaacs thoughts?

bnoordhuis commented 12 years ago

FILE_ATTRIBUTE_READONLY is the only one that's applicable to Unices (except that it won't fail on directories unless checks are put in place - tricky to do atomically). How important is this to you?

jorangreef commented 9 years ago

This would be really useful for me in Node also.

I was thinking it could be a small per-platform api to expose the bits that don't make sense on all platforms, but that we still need to work with to write cross-platform code, similar to how the path module has path.posix and path.win32.

Perhaps the fs module could have fs.win32 (with methods to get attributes, set attributes and get the 8.3 short name for a given path)? fs.posix could have native xattr get/set/list.

saghul commented 9 years ago

Can we fold this into: https://github.com/libuv/libuv/issues/234 ?

jorangreef commented 9 years ago

I think the main issue here is exposing SetFileAttributes. Perhaps 234 could be broadened? I realized this was the old joyent/libuv after posting, and then saw there was no issue for this in the corresponding libuv/libuv repo. Thanks for picking it up.

saghul commented 9 years ago

I think the main issue here is exposing SetFileAttributes. Perhaps 234 could be broadened?

I guess so, feel free to leave some comments / feedback there. As of right now I just close issues that have been resolved in this tracker, and we'll eventually close them all and ask reporters to reopen them in libuv/libuv if they still apply.

piscisaureus commented 9 years ago

Yes, folding this into 234 would have my preference actually. I think there's a lot of overlap between attributes that OS X support and attributes supported by windows, so it makes sense to try and at least found a half-decent abstraction over them.

piscisaureus commented 9 years ago

and get the 8.3 short name for a given path

I would be okay with exposing ACLs/ownership on windows. But 8.3 filenames?! Please... :crying_cat_face:

jorangreef commented 9 years ago

I would be okay with exposing ACLs/ownership on windows. But 8.3 filenames?! Please... :crying_cat_face:

I guess it's a bit of a niche request, but I've been working on a sync tool, and 8.3 filenames can't be ignored on Windows or data would be lost. There's no way to properly figure out the corresponding short name (for a new file, or for an existing file) without asking the filesystem.

Yes, folding this into 234 would have my preference actually. I think there's a lot of overlap between attributes that OS X support and attributes supported by windows, so it makes sense to try and at least found a half-decent abstraction over them.

Do you mean OS X extended attributes and Windows alternate data streams? That makes sense for 234 as it is and I think I mentioned it there. ADS can be read and written using readFile and writeFile with ":" after the file name although it is filesystem dependent not just OS dependent (i.e. will fail on FAT I think). I'm not sure how they can be listed, deleted etc. Although alternate data streams are surely less used then 8.3 filenames! ;)

I originally meant Windows attributes, e.g. HIDDEN, READ-ONLY, SYSTEM. Getters and setters for these.

It would be great if all these things could be added as platform-specific fs.utils (similar to path.posix or path.win32) that are only advertised to work on certain platforms (so we avoid LCD mess), but adding these to core because they're necessary to write cross-platform code. This is similar to Electron. Most of the api is cross-platform, but there are also api's specific to platforms to make a truly cross-platform app possible.

Often the reasoning against this kind of thing is that it's not "cross-platform" in the obvious sense.