This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I'm used to set up my Linux-based web server to have a non-privileged user I'm used to use on modifying files. On server all files are owned by that user and associated with the webserver's group. Their permissions are 0640 and 0750 for directories. If I'm downloading file for edit and then upload it again after change while utilizing temporary files, the file becomes unavailable to webserver as it isn't keeping its group association. before it's user:apache 0640 test.php after saving it has become user:users 0640 test.php
Batch reassigning.
This is an enhancement and not a bug since we don't preserve this information. As a work around, try to check "Upload FIles Directly" - I'm not sure but it could work.
(In reply to comment #2) > This is an enhancement and not a bug since we don't preserve this information. > As a work around, try to check "Upload FIles Directly" - I'm not sure but it > could work. Could you explain in a bit more detail how this is "enhancing" since the option says "Preserve Remote File Permissions" and according to Linux/Unix paradigm for controlling access on files and folders owner AND group are essential part of how a file is accessible. If you don't care about preserving associated group of a remote file why should you care about preserving its permission bits? For sure, it's a way of reading that option text differently ... "preserving permission bits of file" as in "preserving ctime of remote file" in opposition to "preserving what user is or is not permitted to access a file in either way". Taking the former everything's fine and you may turn this DEFECT into a FEATURE-REQUEST to get the latter interpretation some day by enhancing support for remote filesystem's paradigms. I still consider this a bug or at least a feature completed half-way, only.
(In reply to comment #3) > Could you explain in a bit more detail how this is "enhancing" since the option > says > > "Preserve Remote File Permissions" Well, in my experience - but I don't use FTP nearly anywhere so I can be horribly wrong - it is not common to allow FTP user to change file owner and/or group. Usually, user uploads a file and this file has "correct" user and group (usually set by FTP server itself). Also, what to do with newly created files? Now, they are just uploaded because there's no such existing file on a server yet so NetBeans cannot read its permissions - this file is simply uploaded and user must manually fix its permissions (and group, if needed). This would not change. Can anyone provide more details/experiences? Thanks.
BTW what about the owner? What to do if differs? Trying to change it?
(In reply to comment #4) Okay, limited ability to change group association is actually convincing me, though it's possible for a user to chgrp a file unless user isn't member of target group, so it might be possible to preserve an existing group association. On the other hand, it's quite clear that adding new files is out of this problem's scope, since you can't even preserve permission bits then ... BTW: I haven't used FTP for a decade now, but I'm used to use SFTP which AFAIK is quite different in how the server can be controlled. For example, if I'm using WinSCP for transmitting file already existing on server, it's prompting me to confirm replacing it. After confirming prompt file is being uploaded and in result the original group association is kept, though it's not using (In reply to comment #5) > BTW what about the owner? What to do if differs? Trying to change it? For sure, you can't by default. But I still wonder why preserving file permission bits then? My point is, on having permission bits 0640 it shouldn't be preserved when group association isn't kept as well since it's most probably changing something. That's completely different if use see 0644 and you are going to keep that ... if world-foo-ability is to be preserved it might be preserved for sure. But if world (different from group) is excluded from accessing a file in either way, ignoring group association is essential to the file and the software relying on it, thus keeping the bits is breaking something. However, turning a 0640 into a 0644 is no option, too, due to increasing security leaks.
(In reply to comment #6) > But I still wonder why preserving file permission bits then? This functionality wasn't in the initial (S)FTP support, it was added later based on user's feedback; I guess it was for "publicly readable directories" (like "upload" or "public" or whatever), at least that's the only scenario I can think of (as I said, personally I don't use FTP, I use ssh and VCS). Back to this issue - I can add changing of group and I will likely do it (I hope it will be properly supported in both of our 3rd party libraries). Changing of owner is perhaps nonsense since IMHO it will fail in 99.9% of cases... Anyway, thanks for your cooperation.
*** Bug 197698 has been marked as a duplicate of this bug. ***