Reading = making changes



  • I was setting up a game after reinstalling it, which involved copying in certain customizations which were stored on my Linux server. Mostly it went fine, but then at one file Windows popped up a dialog saying "You need permission to perform this action. You require permission from the computer's administrator to make changes to this file." (emphasis mine). "The fuck?" I thought. Why does Windows helpfully pop up UAC when running random executables but not now? I tried renaming the old file out of the way. No effect. Maybe the folder permissions were wrong? No, how could I have renamed the file. Finally I thought to do an ls -l on the file on the Linux box. Turned out its permissions were not enough for samba to read it. Who the hell has designed that dialog in Windows and how did they think that message to be appropriate when the actual error is that the source file could not be read? Had it said that, I would have immediately realized what the problem was, instead of spending a minute getting annoyed at Windows once again tossing up mysterious and misleading errors.



  • @tdb said:

    Who the hell has designed that dialog in Windows and how did they think that message to be appropriate when the actual error is that the source file could not be read? Had it said that, I would have immediately realized what the problem was, instead of spending a minute getting annoyed at Windows once again tossing up mysterious and misleading errors.
     

    afaik, the (generic) design of the dialog/error is intentional, literally "security by obscurity".  Microsoft knows there's a shitload of machines where noob users are administrators by default, so something like this is actually a relatively reliable way to secure the system from enabling them to change files they shouldn't be able to change (e.g. system files, or just anything that they don't have file permissions for by default), even when they formally have the right to change them as they're admins. also notice how strange and obscure is the windows dialog to change file permissions (can't do it from the properties, you have to click the "edit" button), or how strange (and pretty user-hostile) is the process/interface to change file owner. 

    advanced user like you will find out what's going on and be able to solve it in 2 or three minutes, whereas BFU won't have a clue and give up.

    (Raymond Chen had a post hinting on this long time ago)



  • @SEMI-HYBRID code said:

    @tdb said:

    Who the hell has designed that dialog in Windows and how did they think that message to be appropriate when the actual error is that the source file could not be read? Had it said that, I would have immediately realized what the problem was, instead of spending a minute getting annoyed at Windows once again tossing up mysterious and misleading errors.
     

    afaik, the (generic) design of the dialog/error is intentional, literally "security by obscurity".  Microsoft knows there's a shitload of machines where noob users are administrators by default, so something like this is actually a relatively reliable way to secure the system from enabling them to change files they shouldn't be able to change (e.g. system files, or just anything that they don't have file permissions for by default), even when they formally have the right to change them as they're admins. also notice how strange and obscure is the windows dialog to change file permissions (can't do it from the properties, you have to click the "edit" button), or how strange (and pretty user-hostile) is the process/interface to change file owner. 

    You misunderstand. Allow me to clarify my point with some helpful illustrations. If I try to copy a file named regedit.exe from a network drive over the real one, I first get this:

    There is already a file with the same name in this location.  Copy and replace / Don't copy / Copy, but keep both files?

    Selecting the "Copy and replace" option, Windows follows up with this:

    You'll need to provide administrator permission to copy to this folder.

    Notice the "Continue" button with the shield icon on it? I didn't actually try it, but based on prior knowledge that should trigger privilege escalation through UAC and allow me to replace this rather important file. Throughout the process windows is being very helpful and providing detailed explanations.

    However, if I try to copy a text file with 600 permissions (readable only by me the Linux user, not samba) from the same network drive to my own desktop, I instead get this:

    You require permission from the computer's administrator to make changes to this file

    The key point here is that I'm trying to make changes to my own desktop, for which I surely should already have permissions. I can create new files or copy other files to it just fine. I'm not trying to make any changes to the file on the network drive; I'm only trying to read it so I could make a copy. There isn't even anything to protect, since the destination is owned by me and doesn't have an identically named file to replace. Whereas in the case where I really was trying to replace a system file, Windows would have cheerfully let me do it.



  •  @SEMI-HYBRID code said:

    @tdb said:

    Who the hell has designed that dialog in Windows and how did they think that message to be appropriate when the actual error is that the source file could not be read? Had it said that, I would have immediately realized what the problem was, instead of spending a minute getting annoyed at Windows once again tossing up mysterious and misleading errors.
     

    afaik, the (generic) design of the dialog/error is intentional, literally "security by obscurity".  Microsoft knows there's a shitload of machines where noob users are administrators by default, so something like this is actually a relatively reliable way to secure the system from enabling them to change files they shouldn't be able to change (e.g. system files, or just anything that they don't have file permissions for by default), even when they formally have the right to change them as they're admins. also notice how strange and obscure is the windows dialog to change file permissions (can't do it from the properties, you have to click the "edit" button), or how strange (and pretty user-hostile) is the process/interface to change file owner. 

    advanced user like you will find out what's going on and be able to solve it in 2 or three minutes, whereas BFU won't have a clue and give up.

    (Raymond Chen had a post hinting on this long time ago)

     I think you're missing the point. Windows wasn't protecting its system files (he had access rights to write the files); Windows was displaying the wrong error message.

    There's probably some CopyFile-operation happening somewhere, which returns an "Access Denied" error for any access errors, regardless if its reading or writing. So the message just shows the most common cause.

     



  •  oh, so the samba got a request from windows that read "gimme this file". samba tried to open the file to be able to give it to win, but the filesystem told her "you need a permission to perform this action", which samba telegraphed to win, which quoted exactly what it was told.

    btw, reading the file actually makes changes to it(s metadata).

     

    (but yes, i misunderstood and i get your point now, but i don't see anything really WTFy with it.)



  • @SEMI-HYBRID code said:

     oh, so the samba got a request from windows that read "gimme this file". samba tried to open the file to be able to give it to win, but the filesystem told her "you need a permission to perform this action", which samba telegraphed to win, which quoted exactly what it was told.

    Pretty much, except EPERM doesn't indicate the kind of permission that was denied, so that must be inferred from the operation that was attempted. I'm not sure what kind of error codes the SMB protocol has; it's possible that samba gave out the wrong error code, but I hold it more likely that windows got confused about what it was trying to do and presented the wrong operation with the error.

    @SEMI-HYBRID code said:

    btw, reading the file actually makes changes to it(s metadata).

    That depends. If a filesystem is mounted with ro or noatime, reading the file won't change even the metadata. In this case neither of those flags were present, so reading the file would have caused its atime to be updated. Also, changing a file's metadata is largely independent of the permission bits, so if we start picking that nit, we'd need to define a third access type besides read and write. Windows actually has that and a whole lot more. Linux has more fine-grained ACLs for some filsystems as an extension, but for most users the standard read/write/execute bits are enough, with the file's owner and group having fixed permissions to modify the metadata.



  • @tdb said:

    You misunderstand.

    Re-read your first post and then maybe you can solve this great mystery of misunderstanding.

    @tdb said:

    However, if I try to copy a text file with 600 permissions (readable only by me the Linux user, not samba) from the same network drive to my own desktop, I instead get this:

    If I read this literally, the problem is that the file isn't readable by Samba, so obviously Samba can't send it to Windows. But then Windows wouldn't be involved at all, so I can only assume you're "communicating clearly" once more.

    I'm no Linux expert, but isn't 600 "owner-only access"? And isn't the Linux account which owns the file different from the Windows account trying to access it? Have you tried just fixing the permissions? IIRC you need 644 so that anybody can read the file, but only the owner can modify it.

    @tdb said:

    There isn't even anything to protect, since the destination is owned by me and doesn't have an identically named file to replace.

    I wager the problem is that Samba's errors suck shit, and Windows has no way of knowing what to do to make the operation work, and "permission from the computer's administrator" is a catch-all they use in that situation. If my theory's correct, it wouldn't matter what Windows user you tried this under, the problem is on the Linux side.

    I think a bigger question is how you managed to fuck up your file server's permissions so much.



  • @blakeyrat said:

    @tdb said:
    You misunderstand.

    Re-read your first post and then maybe you can solve this great mystery of misunderstanding.

    I've never denied that the misunderstanding might have been my fault. After my clarifications, SEMI-HYBRID got what I meant though, and even agreed that he misunderstood at first. What's that to you anyway?

    @blakeyrat said:

    @tdb said:
    However, if I try to copy a text file with 600 permissions (readable only by me the Linux user, not samba) from the same network drive to my own desktop, I instead get this:

    If I read this literally, the problem is that the file isn't readable by Samba, so obviously Samba can't send it to Windows. But then Windows wouldn't be involved at all, so I can only assume you're "communicating clearly" once more.

    Sure Windows is involved. The error dialog can hardly be displayed by samba. The SMB protocol operates with numeric error codes, so Windows has to come up with a corresponding message too.

    @blakeyrat said:

    I'm no Linux expert, but isn't 600 "owner-only access"?

    Bingo.

    @blakeyrat said:
    And isn't the Linux account which owns the file different from the Windows account trying to access it?

    Yup.

    @blakeyrat said:
    Have you tried just fixing the permissions? IIRC you need 644 so that anybody can read the file, but only the owner can modify it.

    Yes, that's indeed what I did. I thought it was implied, being the only sensible solution to the problem. The post wasn't about fixing the problem anyway, but rather about the error message.

    @blakeyrat said:

    @tdb said:
    There isn't even anything to protect, since the destination is owned by me and doesn't have an identically named file to replace.

    I wager the problem is that Samba's errors suck shit, and Windows has no way of knowing what to do to make the operation work, and "permission from the computer's administrator" is a catch-all they use in that situation.

    The SMB protocol only has a generic "access denied" code, regardless of whether it was read or write access. If the access mode information is needed, the caller needs to keep track of what it was trying to do when the error occurred. In this case the relevant operation would be "open file in read-only mode". However, Windows then goes on to say that the error occurred while trying to modify the file. Since a copy operation involves reading one file and writing another, the obvious conclusion was that the write part somehow failed, but that wasn't the case.

    @blakeyrat said:

    If my theory's correct, it wouldn't matter what Windows user you tried this under, the problem is on the Linux side.

    I think it's possible to share account information between Linux and Windows, but I don't know how it's done or how well it works. I've configured samba to ignore usernames coming from the client because I don't need that in my personal network.

    The "permission from administrator" part is fine; for all Windows knows it could be on a corporate network and the user might really need to contact IT support to get the file access rights fixed.

    @blakeyrat said:

    I think a bigger question is how you managed to fuck up your file server's permissions so much.

    I'll refrain from providing the entire backstory because I don't feel like explaining my reasons to you after every second sentence. Suffice it to say that the file in question was stored somewhere under my home directory on the Linux box, with global read access disabled. I then copied it to the shared directory with cp -a, which preserves timestamps, permissions and other metadata. Thus the file ended up in the shared directory without samba being able to read it.



  • @tdb said:

    I've never denied that the misunderstanding might have been my fault. After my clarifications, SEMI-HYBRID got what I meant though, and even agreed that he misunderstood at first. What's that to you anyway?

    I have made it a life-long goal to encourage people to MAKE FUCKING SENSE. If it's important enough to share with all of us, it's important enough to proofread and ensure we can all understand it.

    Your second version with the screenshots was pretty good, your first version was abominable.

    @tdb said:

    The post wasn't about fixing the problem anyway, but rather about the error message.

    Ok...

    @tdb said:

    The "permission from administrator" part is fine; for all Windows knows it could be on a corporate network and the user might really need to contact IT support to get the file access rights fixed.

    Gruh-huh?

    Ok, so we've established:
    1) a UAC prompt wouldn't have fixed your problem, as it was entirely server-side (your initial complaint, as far as I can make it out, was that there was no UAC elevation in the dialog)
    2) you have an issue with the error message
    3) the error message is fine

    So... what are we all doing here again?

    @tdb said:

    I'll refrain from providing the entire backstory because I don't feel like explaining my reasons to you after every second sentence. Suffice it to say that the file in question was stored somewhere under my home directory on the Linux box, with global read access disabled. I then copied it to the shared directory with cp -a, which preserves timestamps, permissions and other metadata. Thus the file ended up in the shared directory without samba being able to read it.

    One of the (many) issues I have with Linux users is how much they tinker with shit. I used to know this guy (well, actually he was an OS X developer, but same difference) who would constantly create problems for himself and then whinge to me about them, and my response would always be: "you know if you just used the system instead of trying to tinker with permissions, or mount a filesystem with some weird flag that disables last access time, or whatever you did this week to fuck up your computer-- if you just used it as its intended to be used, you wouldn't have any goddamned problems at all."

    So my advice to you would be: just stop tinkering with shit, and it'll work fine. If you're going out-of-your-way to use the "uncommon" option, like using cp -a instead of just cp (or, fuck, for that matter using the CLI instead of just dragging the file icons (or, fuck, for that matter using Linux at all instead of a sane OS)) then your life would be much easier.



  • @blakeyrat said:

    I wager the problem is that Samba's errors suck shit, and Windows has no way of knowing what to do to make the operation work, and "permission from the computer's administrator" is a catch-all they use in that situation. If my theory's correct, it wouldn't matter what Windows user you tried this under, the problem is on the Linux side.

    In theory, that's possible, especially once you consider that the most obvious guess is so often incorrect, and you're not looking at the right thing. However, windows should at least understand that it's reading from the network source, not writing. My guess is that the place that pops up the message makes some call to copy the system, and isn't looking at what the real error is, or even where it came from.

    @blakeyrat said:

    I think a bigger question is how you managed to fuck up your file server's permissions so much.


    There are some files (especially ssh configuration stuff) that is required to have those sorts of permissions in order to actually work. It's hard to say if it's really fucked up without knowing more.



  • @boomzilla said:

    There are some files (especially ssh configuration stuff) that is required to have those sorts of permissions in order to actually work. It's hard to say if it's really fucked up without knowing more.

    This is an .ini file that configures a video game.

    If an .ini file that configures a Windows video game is required, when stored on Linux, to have special permissions, then I will eat not only my hat, but every hat in Texas.



  • @blakeyrat said:

    @boomzilla said:
    There are some files (especially ssh configuration stuff) that is required to have those sorts of permissions in order to actually work. It's hard to say if it's really fucked up without knowing more.

    This is an .ini file that configures a video game.

    If an .ini file that configures a Windows video game is required, when stored on Linux, to have special permissions, then I will eat not only my hat, but every hat in Texas.

    You're right. That file shouldn't have gotten the permissions messed up like that. I wonder if it was something that some brain dead game stored something in Program Files or something.



  • @blakeyrat said:

    @tdb said:
    I've never denied that the misunderstanding might have been my fault. After my clarifications, SEMI-HYBRID got what I meant though, and even agreed that he misunderstood at first. What's that to you anyway?

    I have made it a life-long goal to encourage people to MAKE FUCKING SENSE. If it's important enough to share with all of us, it's important enough to proofread and ensure we can all understand it.

    So I've noticed. Unfortunately it seems that your standards of making sense are so far off from everyone else that it's extremely hard to please you. The original post made sense to me; geocities also understood it well enough to correct SEMI-HYBRID at about the same time as I did (his timestamp is only three minutes later than mine, so I assume he was already writing his reply when I hit the "Post" button).

    @blakeyrat said:

    Your second version with the screenshots was pretty good, your first version was abominable.

    I thought the case was simple enough to not need screenshots. When clarification was asked for, screenshots were the easiest way to make sure I'm understood.

    @blakeyrat said:

    @tdb said:
    The "permission from administrator" part is fine; for all Windows knows it could be on a corporate network and the user might really need to contact IT support to get the file access rights fixed.

    Gruh-huh?

    Ok, so we've established:
    1) a UAC prompt wouldn't have fixed your problem, as it was entirely server-side (your initial complaint, as far as I can make it out, was that there was no UAC elevation in the dialog)
    2) you have an issue with the error message
    3) the error message is fine

    So... what are we all doing here again?

    Since the extra detail I put in to embellish the story a bit apparently confuses you, and my explanations also seem to be ineffective, let me provide an abridged version of the wtf with only the bare essentials. To avoid further confusion, please ignore any previously provided details while reading this.

    My fileserver had a file owned by a local user and only readable by that user. I tried to copy it over the network to my Windows machine. Windows said it didn't have permission to modify the file. The actual problem was that Windows couldn't read the file. I found it annoying that the error message didn't describe the actual cause of the error.

    @blakeyrat said:

    @tdb said:
    I'll refrain from providing the entire backstory because I don't feel like explaining my reasons to you after every second sentence. Suffice it to say that the file in question was stored somewhere under my home directory on the Linux box, with global read access disabled. I then copied it to the shared directory with cp -a, which preserves timestamps, permissions and other metadata. Thus the file ended up in the shared directory without samba being able to read it.

    One of the (many) issues I have with Linux users is how much they tinker with shit. I used to know this guy (well, actually he was an OS X developer, but same difference) who would constantly create problems for himself and then whinge to me about them, and my response would always be: "you know if you just used the system instead of trying to tinker with permissions, or mount a filesystem with some weird flag that disables last access time, or whatever you did this week to fuck up your computer-- if you just used it as its intended to be used, you wouldn't have any goddamned problems at all."

    So my advice to you would be: just stop tinkering with shit, and it'll work fine. If you're going out-of-your-way to use the "uncommon" option, like using cp -a instead of just cp (or, fuck, for that matter using the CLI instead of just dragging the file icons (or, fuck, for that matter using Linux at all instead of a sane OS)) then your life would be much easier.

    See? This is exactly why I didn't bother telling more details.



  • @boomzilla said:

    You're right. That file shouldn't have gotten the permissions messed up like that. I wonder if it was something that some brain dead game stored something in Program Files or something.

    Fine, I'll explain it, but only since it's you and not blakey asking. I started playing that game with Wine under Linux. Since I provide shell accounts on my server for some friends and an somewhat paranoid by nature, I had set up permissions so that other users didn't have access to the game files. Thus the file ended up on my file server with no global read permission. A while ago I got tired with Wine not working quite right and switched to Windows as a gaming platform (I have my reasons to still use Linux for most purposes, but they are mostly ideological so I won't bother explaining them). Thus the need to copy said file to Windows.

    The game in question is a bit braindead too and writes stuff, including configuration, to its installation directory. It's known to break horribly if installed to Program Files under Vista or 7. That was not the source of the permission problem though.



  • @tdb said:

    @boomzilla said:
    You're right. That file shouldn't have gotten the permissions messed up like that. I wonder if it was something that some brain dead game stored something in Program Files or something.

    Fine, I'll explain it, but only since it's you and not blakey asking. I started playing that game with Wine under Linux. Since I provide shell accounts on my server for some friends and an somewhat paranoid by nature, I had set up permissions so that other users didn't have access to the game files. Thus the file ended up on my file server with no global read permission. A while ago I got tired with Wine not working quite right and switched to Windows as a gaming platform (I have my reasons to still use Linux for most purposes, but they are mostly ideological so I won't bother explaining them). Thus the need to copy said file to Windows.

    That makes sense to me.



  • @tdb said:

    I started playing that game with Wine under Linux. Since I provide shell accounts on my server for some friends and an somewhat paranoid by nature, I had set up permissions so that other users didn't have access to the game files. Thus the file ended up on my file server with no global read permission. A while ago I got tired with Wine not working quite right and switched to Windows as a gaming platform.  Thus the need to copy said file to Windows.

    The game in question is a bit braindead too and writes stuff, including configuration, to its installation directory. It's known to break horribly if installed to Program Files under Vista or 7. That was not the source of the permission problem though.

    Lesson of the day.   That should have been your first post.

     



  • If it makes you feel better Mac has a similar issue:

    (I'm trying snag.gy and it fails on alpha transparency)

    That was a file with 600 permissions on the samba server.

    However I managed to copy a file with the same name over it (I had write permission to the directory). Finder tends to delete files before overwriting. It does this to folders too, which is a bit of a WTF (One'd expect a merge).

    If I don't have write permission to the directory it asks for username/password (UAC style) but supplying that it just fails.

    Just today I moved some files from my local HDD to the server, but upon completion one just disappeared. No trace anywhere. Luckily it was just a downloaded file (albeit 1.65GB which will take a few hours to download again on this crappy ADSL), but it does not instill confidence in the system.



  • @Zemm said:

    (I'm trying snag.gy and it fails on alpha transparency)

    It seems to fail in general since the image is not visible, not even when viewed directly on snag.gy.



  • @El_Heffe said:

    @tdb said:
    I started playing that game with Wine under Linux. Since I provide shell accounts on my server for some friends and an somewhat paranoid by nature, I had set up permissions so that other users didn't have access to the game files. Thus the file ended up on my file server with no global read permission. A while ago I got tired with Wine not working quite right and switched to Windows as a gaming platform.  Thus the need to copy said file to Windows.

    The game in question is a bit braindead too and writes stuff, including configuration, to its installation directory. It's known to break horribly if installed to Program Files under Vista or 7. That was not the source of the permission problem though.

    Lesson of the day. That should have been your first post.
    Why? That sort of circumstantial information has (at least to me) no relevance to the WTF illustrated in the original post.

     



  • @Zemm said:



    If it makes you feel better Mac has a similar issue:

    I would say that the Mac message is better, since it isn't wrong. The message from Windows implies that your problem is local, not on the file server. This sort of an error at least doesn't lead you in the wrong direction.



  • @tdb said:

    You require permission from the computer's administrator to make changes to this file

    Wait wait wait, why does this error message not make sense to you? In particular, why are you assuming that "the computer" as mentioned in the error message is the local machine? It seems clear to me that this dialog is saying that you need special permissions from the network machine you're trying to get the file from to perform the requested operation. It could have been more clear, sure (it could have specified "the remote computer's administrator") but it is technically correct as stated. How can it refer to the local machine when that file doesn't yet exist on the local machine?



  • @UrzaMTG said:

    @tdb said:

    You require permission from the computer's administrator to make changes to this file

    Wait wait wait, why does this error message not make sense to you? In particular, why are you assuming that "the computer" as mentioned in the error message is the local machine?

    Because of the phrase "make changes to this file." He wasn't doing that, he was copying it to another drive. As a user, if I'm trying to copy a file and the computer is trying to make changes to it, that's a huge problem.



  • @dcardani said:

    @UrzaMTG said:
    @tdb said:

    You require permission from the computer's administrator to make changes to this file

    Wait wait wait, why does this error message not make sense to you? In particular, why are you assuming that "the computer" as mentioned in the error message is the local machine?

    Because of the phrase "make changes to this file." He wasn't doing that, he was copying it to another drive. As a user, if I'm trying to copy a file and the computer is trying to make changes to it, that's a huge problem.

     

    Windows Stores 3 dates in the metadata: last access time, creation time, and last modified. Linux also stores those dates although only the last modified time is generally shown for both. When you copy a file it changes the last accessed time for the original, and creation time for the copy. Due to linux's wierd ways, that metadata is protected for read-only files unlike how it is not protected with windows. Hence why you can copy a read-only file in windows but not linux.



  • @UrzaMTG said:

    @tdb said:

    You require permission from the computer's administrator to make changes to this file

    Wait wait wait, why does this error message not make sense to you? In particular, why are you assuming that "the computer" as mentioned in the error message is the local machine? It seems clear to me that this dialog is saying that you need special permissions from the network machine you're trying to get the file from to perform the requested operation. It could have been more clear, sure (it could have specified "the remote computer's administrator") but it is technically correct as stated. How can it refer to the local machine when that file doesn't yet exist on the local machine?

    In the first attempt, the local file did exist and I was trying to copy a new version over it. Depending on how the copy operation is implemented, it might remove the old file and create a new one, or just overwrite the existing file. In either case, making changes to the file is required (new files start out empty, so in the general case you'll have to write to it to copy the contents), and in case of creating a new file, also to the directory containing it. I certainly wasn't trying to make any changes on the file server.



  • @Steeldragon said:

    Windows Stores 3 dates in the metadata: last access time, creation time, and last modified. Linux also stores those dates although only the last modified time is generally shown for both. When you copy a file it changes the last accessed time for the original, and creation time for the copy. Due to linux's wierd ways, that metadata is protected for read-only files unlike how it is not protected with windows. Hence why you can copy a read-only file in windows but not linux.

    That's not quite correct. On Linux, the file's owner has near complete control over the file's metadata, regardless of the permission bits. The only restrictions are that only root can set the owner, and normal users can only change the file's group to one that the user is a member of. (Obviously metadata directly pertaining to the file's contents, such as its size, needs to stay in sync with the contents so write access is required.) Access time is updated regardless of who's accessing the file, as long as the filesystem mount flags allow it (ro and noatime are unset). Also, executing a file apparently doesn't count as accessing it.

    When copying a file, the new file usually exists with default permissions and timestamps until the contents are written, and then the metadata is copied over. It's also possible to use the open() syscall in a way that creates a read-only file but returns a read-write file descriptor, but other metadata must always be set manually (though setting it won't require write permission on the file).



  • @Zemm said:

     

    No-o-o-body expects the -8084 condition!

     



  • Only root can set the owner? Odd, I was pretty sure that the owner could transfer ownership to someone else... of course, I haven't used Linux in ages, and I never got much into it anyway...



  • @ekolis said:

    Only root can set the owner? Odd, I was pretty sure that the owner could transfer ownership to someone else... of course, I haven't used Linux in ages, and I never got much into it anyway...

    Nope. If you want chown without root, you need to make your files readable, and let the other user make a copy.



    Blakeykitten seems confused about what the actual problem is. It isn't that the file wasn't copied. And it isn't that Windows is recommending we talk to an administrator. The problem is the error "I can't write" being reported when the cause is actually "I can't read."



    I don't know enough about SMB to know whether it's a mistake in Windows or not, though. Maybe SMB has specific error messages like this built in?



    Windows definitely shouldn't care if the read causes implicit writes on the remote machine, though. Otherwise [basically] every read error could be called a write error, and that just wouldn't be helpful.



  • @superjer said:

    The problem is the error "I can't write" being reported when the cause is actually "I can't read."

    But to get to "I can't write" you need to pass through "I can't read" first. Depending on how and when SMB reports the error, Windows might have no clue which part (the reading, or the writing) was the issue, and reported "write" because that was the actual operation you were trying to do.

    Despite your assertion about me being confused, I expressed that same position with slightly different wording a few days back, maybe you missed it.



  • @blakeyrat said:

    Depending on how and when SMB reports the error, Windows might have no clue which part (the reading, or the writing) was the issue, and reported "write" because that was the actual operation you were trying to do.

    It is my understanding that the only thing Windows should even think is being attempted over SMB is a read. The write would have occurred locally, had the read succeeded.



  • @da Doctah said:

    No-o-o-body expects the -8084 condition!
     

    WTF kind of HTML did you manage to shove into CS-- and WTF did it send to gmail-- and WTF didn't gmail filter this?

    @Aywwww yeaaah! Butt shits to your box, biznitches! said:





  • @Steeldragon said:

    Windows Stores 3 dates in the metadata: last access time, creation time, and last modified. Linux also stores those dates although only the last modified time is generally shown for both. When you copy a file it changes the last accessed time for the original, and creation time for the copy. Due to linux's wierd ways, that metadata is protected for read-only files unlike how it is not protected with windows. Hence why you can copy a read-only file in windows but not linux.

    So what you're saying here is that in order to read a read-only file under linux, you need write access so the "last access time" metadata can be updated?



  • @superjer said:

    @blakeyrat said:
    Depending on how and when SMB reports the error, Windows might have no clue which part (the reading, or the writing) was the issue, and reported "write" because that was the actual operation you were trying to do.

    It is my understanding that the only thing Windows should even think is being attempted over SMB is a read. The write would have occurred locally, had the read succeeded.

    I think you are all confusing "reading a file" as perceived by an end-user with the actual actions that Windows performs. There are plenty of examples where Windows modifies a file when you only asked to read it. For illustration [url]http://blogs.msdn.com/b/oldnewthing/archive/2011/08/16/10195932.aspx[/url]

    If the Windows message says that the write failed, I'm pretty confident it failed to write... in this case to the original file. I'm not sure if Sysinternals ProcessMonitor works on Samba shares but it could give you a trace of exactly what Windows is trying to achieve



  • @bjolling said:

    If the Windows message says that the write failed, I'm pretty confident it failed to write... in this case to the original file. I'm not sure if Sysinternals ProcessMonitor works on Samba shares but it could give you a trace of exactly what Windows is trying to achieve

    Not necessarily; you don't know what abstraction level Explorer is working at. The library Explorer is asking to do the actual operation might not return a distinct error message for "failed to write because I can't read from the server".

    If I'm in a normal Windows program, and I try to write a file, and it fails because of a bad block on the HD, I don't get an error code that reads, "failure to write file because Sector 34038 of the HD didn't return the correct checksum". That level of detail is abstracted away. All I get is "hey something went wrong."



  • @blakeyrat said:

    If I'm in a normal Windows program, and I try to write a file, and it fails because of a bad block on the HD, I don't get an error code that reads, "failure to write file because Sector 34038 of the HD didn't return the correct checksum". That level of detail is abstracted away. All I get is "hey something went wrong."
     

    And that's fine. Wrong would be if it told you "You haven't permission to write in this folder. Contact the Computer Administrator."

     



  • @Ilya Ehrenburg said:

    @blakeyrat said:

    If I'm in a normal Windows program, and I try to write a file, and it fails because of a bad block on the HD, I don't get an error code that reads, "failure to write file because Sector 34038 of the HD didn't return the correct checksum". That level of detail is abstracted away. All I get is "hey something went wrong."
    And that's fine. Wrong would be if it told you "You haven't permission to write in this folder. Contact the Computer Administrator."

    Is there like an Eagle Scout Merit Badge for "missing the point"?

    Look:
    1) You tell Explorer to copy a file to a folder (i.e. write a file)
    2) Explorer tells its library to copy a file to a folder
    3) Library returns an generic error "failed"
    4) Explorer doesn't have any information on the operation other than a) it was an attempt to write a file, b) the attempted failed
    5) Explorer presents a dialog box to the user saying "an attempt to write this file failed, using an Administrator account might fix this"

    Now where in the above is Explorer's WTF? Which step?



  • @blakeyrat said:

    @Ilya Ehrenburg said:

    @blakeyrat said:

    If I'm in a normal Windows program, and I try to write a file, and it fails because of a bad block on the HD, I don't get an error code that reads, "failure to write file because Sector 34038 of the HD didn't return the correct checksum". That level of detail is abstracted away. All I get is "hey something went wrong."
     

    And that's fine. Wrong would be if it told you "You haven't permission to write in this folder. Contact the Computer Administrator."

     

    Is there like an Eagle Scout Merit Badge for "missing the point"?

    Look:
    1) You tell Explorer to copy a file to a folder (i.e. write a file)
    2) Explorer tells its library to copy a file to a folder
    3) Library returns an generic error "failed"
    4) Explorer doesn't have any information on the operation other than a) it was an attempt to write a file, b) the attempted failed
    5) Explorer presents a dialog box to the user saying "an attempt to write this file failed, using an Administrator account might fix this"

    Now where in the above is Explorer's WTF? Which step?

     

    Your parenthesis to 1) is wrong. A copy consists not only of writing. So after 3), in 4), Explorer has the information that an attempt to copy a file failed, but not which particular step failed in what way. So instead of saying "an attempt ...", it should rather say "Couldn't copy the file. Nobody told me exactly what went wrong, so I can't tell you either. Sorry."

     



  • @Ilya Ehrenburg said:

    Your parenthesis to 1) is wrong. A copy consists not only of writing.

    Well duh, but the user's intention was to write a file. And the user's intention is the important thing here. Nobody gives a shit that copying a just involves reading and writing, just as nobody gives a shit that when you hit "save" the file goes to inode 567723 in sector 46232 of the drive on platter 0.

    @Ilya Ehrenburg said:

    it should rather say "Couldn't copy the file. Nobody told me exactly what went wrong, so I can't tell you either. Sorry."

    Yeah the tech press would have lapped that up.



  • @blakeyrat said:

    @Ilya Ehrenburg said:
    Your parenthesis to 1) is wrong. A copy consists not only of writing.

    Well duh, but the user's intention was to write a file. And the user's intention is the important thing here. Nobody gives a shit that copying a just involves reading and writing, just as nobody gives a shit that when you hit "save" the file goes to inode 567723 in sector 46232 of the drive on platter 0.

    You're right, of course, about the user's intention. What if the user were trying to copy something over the network (as in the original example) and the network connection was lost between the time the user selected the file, and when the operation was started? By your logic, it's OK (i.e., not misleading) to claim that the failure was while writing something.

    This is just a more obvious case about why you're still wrong on the main point. The bigger question is why you persist in this. Usually, you're all over software that says misleading, vague or cryptic things (especially installers).



  • @blakeyrat said:

    @Ilya Ehrenburg said:
    Your parenthesis to 1) is wrong. A copy consists not only of writing.

    Well duh, but the user's intention was to write a file.

    How do you know? The user gave a copy command, so perhaps it was the intention to copy the file?

    And the user's intention is the important thing here.

    True, but it's unknown.

    Nobody gives a shit that copying a just involves reading and writing,

    Wrong, some people do.

    @Ilya Ehrenburg said:
    it should rather say "Couldn't copy the file. Nobody told me exactly what went wrong, so I can't tell you either. Sorry."

    Yeah the tech press would have lapped that up.

     

    Of course it would have to be phrased more professionally.

    But seriously, if all that Explorer gets is "generic error xyz, operation failed", it shouldn't pretend to know what exactly went wrong. If part (hopefully only part) of the tech press has a go at Microsoft for letting Explorer admit that it hasn't been given sufficient detail to present the user with an accurate message and fix-suggestion, does Microsoft care? More importantly should it/they care? (In case it's not obvious, IMO Microsoft should not care.)



  • @boomzilla said:

    By your logic, it's OK (i.e., not misleading) to claim that the failure was while writing something.

    I'm not saying it's right, or that the message is perfect or that it can't be greatly improved. You've all earned your merit badge.

    All I'm saying is: at the level of abstraction Explorer is (likely) operating on the error message is the best possible. (With the corollary: if Explorer were modified to operate at a lower level of abstraction, it likely could produce better error messages.)

    That's it, that's the entire point I'm making.

    Now I'm going to huddle into a ball and hate you all for awhile.



  • @Ilya Ehrenburg said:

    @blakeyrat said:
    @Ilya Ehrenburg said:
    Your parenthesis to 1) is wrong. A copy consists not only of writing.

    Well duh, but the user's intention was to write a file.

    How do you know? The user gave a copy command, so perhaps it was the intention to copy the file?

    ... how is writing a new file different from copying an existing file, intent-wise? Are we drifting into philosophy? I'm mystified by where you're going with this...



  • @blakeyrat said:

    That's it, that's the entire point I'm making.

    And that's the point we dispute. It would be better if the error message said that the cause is unknown.


     



  • @blakeyrat said:

    @Ilya Ehrenburg said:
    @blakeyrat said:
    @Ilya Ehrenburg said:
    Your parenthesis to 1) is wrong. A copy consists not only of writing.

    Well duh, but the user's intention was to write a file.

    How do you know? The user gave a copy command, so perhaps it was the intention to copy the file?

    ... how is writing a new file different from copying an existing file, intent-wise? Are we drifting into philosophy? I'm mystified by where you're going with this...

     

    Oy.

    Write a new file: create some data, programmatically or by having the user type text in an editor, whatever; write that data to disk.

    Copy a file: read data from disk; write that data to another place on the disk (or a different disk) too.

    Can't you really see the difference?



  • @blakeyrat said:


    All I'm saying is: at the level of abstraction Explorer is (likely) operating on the error message is the best possible. (With the corollary: if Explorer were modified to operate at a lower level of abstraction, it likely could produce better error messages.)

    That's it, that's the entire point I'm making.

    And you still haven't read closely what we've all been saying. Assuming that you're correct about the level of abstraction, then the error message is making stuff up. It doesn't know that the problem was that it couldn't write anything. But the message talks about a write error. If it simply said that the copy operation failed, then it would be giving an abstraction appropriate error message. But it's guessing about what went wrong, and in this case, getting it wrong.

    And that is why your point is still wrong. Re-read the other example I gave, which should look identical to Explorer as the OP's situation. Do you still really think that would be an appropriate error message?



  • @bjolling said:

    If the Windows message says that the write failed, I'm pretty confident it failed to write... in this case to the original file. I'm not sure if Sysinternals ProcessMonitor works on Samba shares but it could give you a trace of exactly what Windows is trying to achieve

    Then how do you explain that it's able to copy a file with 444 permissions (readable by everybody, writable by nobody) off the file server? If it wanted to write to the original file, that operation should fail as well. Also, the original's mtime doesn't change.



  • @blakeyrat said:

    @Ilya Ehrenburg said:

    And that's fine. Wrong would be if it told you "You haven't permission to write in this folder. Contact the Computer Administrator."

    Is there like an Eagle Scout Merit Badge for "missing the point"?

    If there is, you should be awarded one for so studiously missing mine. That analogy is actually pretty good. I'll present another:

    You ask your secretary to get you a copy of a document stored in a filing cabinet. The secretary comes back telling that the copier produced a blank page. You think that the copier might be out of ink and call a repair man. When the repair man arrives, it turns out that the actual problem was the filing cabinet being locked.

    @blakeyrat said:

    Look:

    1) You tell Explorer to copy a file to a folder (i.e. write a file)

    2) Explorer tells its library to copy a file to a folder

    3) Library returns an generic error "failed"

    4) Explorer doesn't have any information on the operation other than a) it was an attempt to write a file, b) the attempted failed

    5) Explorer presents a dialog box to the user saying "an attempt to write this file failed, using an Administrator account might fix this"

    Now where in the above is Explorer's WTF? Which step?

    I'm fairly certain that Explorer is operating at a lower level of abstraction than that. After all, it's able to tell if the destination file exists and ask me if I want to replace it. It's also able to monitor the progress of the copy operation and tell how much time is left (even though the estimate is often wildly inaccurate). The actual flow is probably more like this:

    1. User tells Explorer to copy a file
    2. Explorer tries to open the file for reading
    3. The CreateFile* call fails, returning ERROR_ACCESS_DENIED
    4. ???
    5. Explorer reports that it couldn't write to a file

    * Yes, CreateFile is used for opening existing files. The "create" part refers to the file handle it returns.



  • @blakeyrat said:

    @Ilya Ehrenburg said:
    @blakeyrat said:
    @Ilya Ehrenburg said:
    Your parenthesis to 1) is wrong. A copy consists not only of writing.

    Well duh, but the user's intention was to write a file.

    How do you know? The user gave a copy command, so perhaps it was the intention to copy the file?

    ... how is writing a new file different from copying an existing file, intent-wise? Are we drifting into philosophy? I'm mystified by where you're going with this...

    If copying is the same as writing arbitary new files, then why do we have a separate command to copy files? You could just open the old file in Notepad and save it to the new location, right?

    A copy operation states "read data from this existing file and write it to that new file". It's distinct from "save this picture I just made into that new file", or "create an empty new file", or "compress the contents of this existing file into that new file". All of these operations result in writing new files, yet they are clearly distinct operations.



  • @blakeyrat said:

    @boomzilla said:
    By your logic, it's OK (i.e., not misleading) to claim that the failure was while writing something.

    I'm not saying it's right, or that the message is perfect or that it can't be greatly improved. You've all earned your merit badge.

    All I'm saying is: at the level of abstraction Explorer is (likely) operating on the error message is the best possible. (With the corollary: if Explorer were modified to operate at a lower level of abstraction, it likely could produce better error messages.)

    That's it, that's the entire point I'm making.

    Actually, it's worse than that.  At the level of abstraction that Explorer is (actually) operating on, it is supposed to receive useful and informative error codes from the SHFileOperationW function, that distinguish between error conditions at source and dest:

    [quote user="http://msdn.microsoft.com/en-us/library/windows/desktop/bb762164(v=vs.85).aspx"]

    DE_SAMEFILE0x71The source and destination files are the same file.
    DE_MANYSRC1DEST0x72Multiple file paths were specified in the source buffer, but only one destination file path.
    DE_DIFFDIR0x73Rename operation was specified but the destination path is a different directory. Use the move operation instead.
    DE_ROOTDIR0x74The source is a root directory, which cannot be moved or renamed.
    DE_OPCANCELLED0x75The operation was canceled by the user, or silently canceled if the appropriate flags were supplied to SHFileOperation.
    DE_DESTSUBTREE0x76The destination is a subtree of the source.
    DE_ACCESSDENIEDSRC0x78Security settings denied access to the source.
    DE_PATHTOODEEP0x79The source or destination path exceeded or would exceed MAX_PATH.
    DE_MANYDEST0x7AThe operation involved multiple destination paths, which can fail in the case of a move operation.
    DE_INVALIDFILES0x7CThe path in the source or destination or both was invalid.
    DE_DESTSAMETREE0x7DThe source and destination have the same parent folder.
    DE_FLDDESTISFILE0x7EThe destination path is an existing file.
    DE_FILEDESTISFLD0x80The destination path is an existing folder.
    DE_FILENAMETOOLONG0x81The name of the file exceeds MAX_PATH.
    DE_DEST_IS_CDROM0x82The destination is a read-only CD-ROM, possibly unformatted.
    DE_DEST_IS_DVD0x83The destination is a read-only DVD, possibly unformatted.
    DE_DEST_IS_CDRECORD0x84The destination is a writable CD-ROM, possibly unformatted.
    DE_FILE_TOO_LARGE0x85The file involved in the operation is too large for the destination media or file system.
    DE_SRC_IS_CDROM0x86The source is a read-only CD-ROM, possibly unformatted.
    DE_SRC_IS_DVD0x87The source is a read-only DVD, possibly unformatted.
    DE_SRC_IS_CDRECORD0x88The source is a writable CD-ROM, possibly unformatted.
    DE_ERROR_MAX0xB7MAX_PATH was exceeded during the operation.

    0x402An unknown error occurred. This is typically due to an invalid path in the source or destination. This error does not occur on Windows Vista and later.
    ERRORONDEST0x10000An unspecified error occurred on the destination.
    DE_ROOTDIR | ERRORONDEST0x10074Destination is a root directory and cannot be renamed.

    [/quote] Unfortunately, MS has gone and buggered it up by trying to make the SHFileOperationW function too clever.  If it gets an error because the source is not accessible, it doesn't return DE_ACCESSDENIEDSRC as you might expect.  Instead it pops up an error dialog on behalf of the client, which at least on w2k reads:

    ---------------------------
    Error Copying File or Folder
    ---------------------------
    Cannot copy New Text Document: Access is denied. The source file may be in use.
    ---------------------------
    OK  
    ---------------------------
    When the user clicks OK, it then decides to return

    ERROR_CANCELLED 1223 (0x4C7) The operation was canceled by the user.

    instead of the actual underlying error.  This is pretty damn misleading of it.  Clearly, the function is a mess; as MSDN says, it could return any of the above error codes, or indeed pretty much any other error code from winerror.h, and in at least some cases (see 0x402 above) it has clearly lost information about what the error really was.  However, this is an implementation bug; at the level of abstraction, if the code had correctly implemented the documented interface, Explorer certainly ought to have been able to diagnose a more precise error.

    In Vista and above, the whole sorry mess has been replaced by the COM interface IFileOperation.  No doubt this was meant to clean up that mess, but equally no doubt it also has bugs causing it to lose track of the real error.




  • @blakeyrat said:

    4) Explorer doesn't have any information on the operation other than a) it was an attempt to write a file, b) the attempted failed

    The thing is, it [i]does[/i] know at least something, because the error dialog doesn't have the option to elevate to admin rights, as it normally does.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.