Go, Go, Gadget Depends!
-
Which, sadly, is exactly what most OSes do.
What OSes do that?
No. What they do is allow applications to hold references to files by path, instead of by file handle (or inode, or whatever terminology your particular OS uses), which results in a de-facto duplication of the file.
The OS itself only does a rename of the file, as it should.
-
Look, you don't like the Windows behavior because it's correct.
How is that desirable behavior? Is this what you think the naive user would expect to happen when a file is renamed?
Are you arguing with yourself again, blakey?
-
As I've stated a couple times before, the issue is that most operating systems and even libraries that abstract OS APIs don't provide any good or useful mechanism for uniquely identifying a file by something other than a string path. Sure, you can get notified of moves and renames, but that's not the same as just storing a UUID that always refers to the file.
I think all rational people agree that this is the actual issue. That doesn't make it less of a bug when I see this behavior in an application.
-
I'd love to fix it in all my applications, but I don't know how.
-
That's great as well, but that still doesn't make it less of a bug.
-
Oh, I thought you meant that it was the application's responsibility. I agree it's a bug with the OS.
-
$ touch blakeyrat.txt
Someone call
Continuation Passing StyleChild Protective Services.Filed Under: Not to say that Blakey is childish, of course...
-
He's very mature, so that lessens the effective age gap.
-
In Mac Classic, it was kind of an application-level thing-- kind of.
Thing is, the API (the Toolbox) made it actually pretty difficult to open a file via. a text-based path. The easy way to do it was to use a file handle. So that's what developers did.
If you're the guy designing APIs, part of your job is to design the API so that the correct behavior is easy and the incorrect behavior is difficult. You know all of those broken Windows apps that used to draw a top-level menu item, but then treat it as a button? WRONG! right? Something like that was REALLY difficult to do in the Toolbox. You'd have to go WAY out of your way to do something like that.
If Microsoft assigned a priority to this, they could easily shim a fix in. Basically keep track of the files an application touches, and do one of their little invisible redirects when the application tries to save the same file back disk. I'm sure that doesn't pass their feature-bar though.
-
Still waiting for citation for that all environment variables are stored in argv.
you can find that by googling. Wikipedia says unix and dos/windows offer a third form of main, which takes a 3rd char ** parameter, envp, but that the "argv contains the environment" is also a real thing. I'd never heard of that before.
-
The point was that
argvis the second argument and doesn't contain any of the third argument.
-
you can find that by googling.
I googled, and googled, and googled, and found no documentation explaining that. I repeat, documentation - some text approved by some committee that some developers decided to implement, not "secret Linux-specific hack" or similar.
-
It would be okay if it was Haskell's type system.
-
-
That's great as well, but that still doesn't make it less of a bug.
It does if you stop using your own made-up definition of the word.
-
The point was that argv is the second argument and doesn't contain any of the third argument.
While I tend to agree, as that's been my experience, see
Other platform-dependent formats are also allowed by the C and C++ standards, except that in C++ the return type must always be int;[6] for example, Unix (though not POSIX.1) and Microsoft Windows have a third argument giving the program's environment, otherwise accessible through getenv in stdlib.h:
int main(int argc, char **argv, char **envp);
Oh, look, either WP is wrong or @ben_lubar is:
By convention, the command-line arguments specified by argc and argv include the name of the program as the first element if argc is greater than 0; if a user types a command of "rm file", the shell will initialise the rm process with argc = 2 and argv = {"rm", "file", NULL}.
-
That program crashes under Windows.
This one doesn't. It also doesn't show any enviroment vars...
-
-
If you want to make sure a file doesn't rename outside the scope of the editor, write one that takes a LOCK on the fucking file. Don't act stupid because that's how naive text editors have worked for 30 years.
You’re not thinking as the average user. If the user opens filefoo.txtand then renames it tobar.txt, in their mind it’s now filebar.txtand no longer filefoo.txt. Computer-savvy users might have a reason to deliberately rename files so that an open program will then save the file under its old name, thereby ending up with two copies, but I doubt the average user will do that.FWIW, OS X, in imitation of Mac OS ≤ 9 before it, handles filenames like that: if you change the name of a file that’s opened in some app, you’ll see the filename displayed at the top of the file’s document window in the app change right away. This works even if you rename the file from the command line, not just from a GUI application such as the Finder.
-
Ok, I didn't actually know this: https://ideone.com/ucOH5w
0 = ./prog 2 = TMPDIR=/tmp/AdMxCW 3 = PATH=/usr/local/bin:/usr/bin:/bin 4 = PWD=/home/IArHry 5 = LANG=en_US.UTF-8 6 = SHLVL=0 7 = HOME=/home/IArHry 9 = (it crashed here)Explanation: https://ideone.com/Ci9thy and https://ideone.com/7xq7K3
-
https://golang.org/src/runtime/runtime1.go#L72
If that's not a C or C++ program I'm not even clicking that link, you silly person.
-
It's where I figured out that environment variables are passed that way. Then I tried it in C and it still worked the same.
-
Is it actually guaranteed though? What's to stop the system from putting the environment vars in a completely separate part of memory from the arguments, requiring you to use the third parameter of
main?
-
Then I tried it in C and it still worked the same.
Not on Windows, with MSVC. I compiled your program with VS2015, and it immediately threw one of these
-
Is it actually guaranteed though? What's to stop the system from putting the environment vars in a completely separate part of memory from the arguments, requiring you to use the third parameter of main?
If it's actually a spec, rather than UB, you'd assume that the two-arg and three-arg versions of main would work differently. (Or maybe not.)
having argv contain the environment seems like a poor design to me, and in fact, when I learned C in the 80s on Unix, you used the three-arg version if you wanted your environment variables (or used getenv()).
-
As per the C standard there's a valid NULL terminator after the last argument, so having the enviroment vars after that is perfectly safe, even if coincidental.
-
As per the C standard there's a valid NULL terminator after the last argument, so having the enviroment vars after that is perfectly safe, even if coincidental.
Yes, but I meant from a design standpoint, it's unaesthetic, having two different things in one variable.
-
Yeah, if it's intended it's definitely a hack.
-
@Gaska said:
Which, sadly, is exactly what most OSes do.
What OSes do that?
No. What they do is allow applications to hold references to files by path, instead of by file handle (or inode, or whatever terminology your particular OS uses), which results in a de-facto duplication of the file.
The OS itself only does a rename of the file, as it should.
The OS sending information about the physical location of a file to a program would be a leaky abstraction. That data is only necessary for the filesystem driver and certain system utilities (disk partitioner, format, chkdsk, defrag, etc...).
-
The OS sending information about the physical location of a file to a program would be a leaky abstraction. That data is only necessary for the filesystem driver and certain system utilities
That doesn't mean it can't be wrapped with something like a UUID. With a UUID, you'd know if the file was renamed, moved, or deleted. With a path, you don't know which of those three things happened, and the usual assumption is that it was deleted.
-
The OS sending information about the physical location of a file to a program would be a leaky abstraction.
... yes? What's your point?
-
The OS sending information about the physical location of a file to a program would be a leaky abstraction.
Have you ever heard of handles?
-
-
Because I know you don't understand how fucking words work:
intrinsic
adjective in·trin·sic \in-ˈtrin-zik, -ˈtrin(t)-sik\ : belonging to the essential nature of a thing : occurring as a natural part of somethingFull Definition of INTRINSIC
1a : belonging to the essential nature or constitution of a thing <the intrinsic worth of a gem> <the intrinsic brightness of a star>
b : being or relating to a semiconductor
in which the concentration of charge carriers is characteristic of the
material itself instead of the content of any impurities it contains
2 a : originating or due to causes within a body, organ, or part <an intrinsic metabolic disease>
b : originating and included wholly within an organ or part <intrinsic muscles> — compare extrinsic 1b — in·trin·si·cal·ly -zi-k(ə-)lē, -si-\ adverbSo no, I don't assume a file named blakey_is_a_derp_tard.png is an image of you illustrating you a derp-tard. I also don't assume a file ending in an extension is actually a file of that format. Something-something-sanitize your shit-puts.
-
So you agree with me that filenames are metadata, yet also somehow simultaneously claim they are data.
-
1a : belonging to the essential nature or constitution of a thing
Show me a file system that doesn't identify files by file names.
Edit: From an end user perspective. Because I don't want to deal with a bunch of Unix inode bullshit at the moment.
-
lncan make two filenames refer to the same file.
rmcan make zero filenames refer to a (still valid) file.
-
I thought I said no Unix bullshit! Goddamnit! You are all the worst.
-
-
You and @ben_lubar can go masturbate into each others face. Am I doing this right?
-
Am I doing this right?
Eww, no, that's just gross. Besides, aren't you supposed to bukkake onto a girl?
TIL Chrome's spell check doesn't know that word.
-
Show me a file system that doesn't identify files by file names.
Most unix filesystems. NTFS might as well; I don't know its internals well enough to say for sure one way or the other. The main filesystem family that used names as sole identifiers was FAT, which was a pretty horrible filesystem that grew out of something designed for floppy disks.
-
If someone knows how to detect renames/moves on Windows and/or on *nix, link me to the API documentation.
Linux specific, I have not used this myself: http://linux.die.net/man/7/inotify .
You can do (almost) anything with just file descriptors in linux. For example, there are system calls to 'open file
foo.txtin the directory represented by this file descriptor'. These functions allow you to work around certain potential security problems. But the posix standard functions are all path-based.My vim in a fairly standard configuration does not keep the file open, and hence recreates the file under the original name if you move it away. I do not know if different editors behave better, and whether this behaviour can be cured.
-
But does that work when the file is moved from the hard drive to a flash drive or vice-versa? I don't think this can be solved at the filesystem level; it's something the operating system has to track.
-
You cannot do a real, technical rename across filesystems. It's always a copy-and-delete-source, and at least on linux that is always done in userspace (the
renamefamily sytem call will fail withEXDEV) so the kernel does not know the move-across-filesystems happened.
-
Right, but there's nothing stopping the OS from having a standard way to move a file from one filesystem to another and notify applications about that at a high level. Just because the underlying implementation is to erase the file on the old filesystem and create it on the new filesystem doesn't mean that you have to interpret it that way. A decent text editor like Notepad++ or Sublime Text shouldn't have to be limited by the underlying mechanism for moving a file.
-
Definitely true, though it's still complicated to model. You'd have to still error out if there are multiple (hard-)links to the source file, because then you unavoidably end up with 2 files. Though I think nowadays linux does keep track of which link to a file was used to open it.
-
Ah, good point - in the discussion about giving files UUIDs I completely forgot about hardlinks. Each hardlink should have its own UUID, or whatever is needed to differentiate them.
-
You and @ben_lubar can go masturbate into each others face. Am I doing this right?
-
The links point to the same data. You can't update one link's data individually, only all at once, because there's only one file. Creating a hardlink then removing the original is equivalent to a rename except for some timing concerns.
Entry point - Wikipedia
- The Go Programming Language
