I don't know how it works on non-Unix systems, but on Unix,
the owner will be the EUID of the process. That is, if the
process at the moment of the mkdir has root priviledges, the
new directory will be owned by root. Otherwise, it will be
owned by whichever user the process was running as.
This is indeed something that has nothing to do with Perl,
but all with the OS. It's unclear to me what you mean by
"server". (Disk server? FTP server? Mail server? NFS server?
NIS server? Application server? Database server? Jumpstart
server? Media server? Quake server?) Not that that is relevant. Some, insecure, OSses allow you to "give away" files, but more secure OSses will not allow you to determine
who owns files or directories.
Abigail | [reply] |
Very true, some implementations of NFS also will squash unknown users (UID 412 on the local server does not exist on the remote server so file created by user id 412 over nfs can be squashed to nobody's UID). this is also the default behavior for root's UID on files created accross NFS. You can disable this with the share/export and the mount options but it opens up some pretty severe security issues... If the OP would be more clear on the actual servers/protocols used we can give better answers. and aye this has nothing to do with perl.
-Waswas
| [reply] |
It will be owned by the user the program is running as. If the directory is sometimes owned by root, then it is probably that you are sometimes running the script as root.
We're not surrounded, we're in a target-rich environment! |
---|
| [reply] |
Depending what you mean by "shared" server? NFS? SMB? something else? Some file systems don't support ownership, or at least not in the same way that a unix fs supports it. In that case, the "apparent" ownership of the files on the server might be determined by the process that mounted the directories on your desktop, or by some mount option.
-- zigdon
| [reply] |
| [reply] [d/l] |
Well, yeah, but what has file permission to do with ownership?
Abigail
| [reply] |